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2 (57) Abstract: A transaction server (112) receives transaction profiles from market parties (102) corresponding to at least three 
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APPARATUS, SYSTEM AND METHOD FOR MANAGING TRANSACTIONS 
BETWEEN MARKET PARTIES FROM MULTIPLE MARKET PARTY CLASSES 

RELATED PATENT APPLICATIONS 

5 

This is a continuation-in-part of Application Number 09/573.711, entitled 
"Apparatus, System and Method for Managing Transaction Profiles Representing 
Different Levels of Market Party Commltmenf , filed on May 18. 2000, which is a 
continuation-in-part of Application Number 09/564.164, entitled "Apparatus, 
10 System And Method For Managing Transaction Profiles Representing Different 
Levels Of Market Party Commitmenr, filed on May 03. 2000. 



BACKGROUND OF THE INVENTION 
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The Invention relates in general to electronic markets and more 

specifically to managing transaction profiles submitted by market parties through 

a communication network. 

~ Communication systems are increasingly being used to provide a medium 
20 for facilitating commercial transactions, advertising and the exchange of 

infonnation. The popularity of the Internet has allowed vendors to provide 

infomnation regarding their products and services, as well as advertise, to a large 

number of potential customers, Buyers can purchase products and bid 

electnDnically through the Internet network, 
25 Conventional electronic transaction techniques, however, are limited in 

several ways. In general, most conventional systems are based on hard-coded 

mechanisms of matching and negotiation. 

For example, many conventional systems, particularly those that are 

auction based, perfomi one-to-many matching and not many-to-many matching. 
30 These conventional systems, therefore, allow a seller to pick between many 

buyers based on price but do not allow for the buyer to select between many 

sellers. 

Another restriction of conventional auction and exchange systems is that . 
buyers and sellers are compared and matched purely on the basis of price and 
35 quantity. In commercial transactions, however, other parameters such as credit 
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terms, delivery dates, quality parameters play Just as Important a role in choosing 

a supplier or buyer as price and quantity. 

Existing systems are limited to providing matching services between only 

two types of parties such as a buyer and seller. The best match, however, of 
5 buyer and seller will often depend crucially on the availability of third-party 

enablers such as logistics, insurance or finance. Conventional systems do not 

allow a transaction to be formed involving more than two parties. 

Therefore, there is need for an apparatus, system and method for 

managing transaction profiles submitted by market parties belonging to multiple 
10 marlcet party classes through a communication networl<. 

SUMMARY OF THE INVENTION 

In an exemplary embodiment of the invention, a transaction server is 
connected to several marl<et parties through a communication network. Market 

15 parlies submit transaction profiles to the transaction server where each 
transaction profile describes a suggested transaction corresponding to the 
market party submitting the profile. Each transaction profile includes at least two 
transaction attributes where each transaction attribute is directed to a different 
market party class and includes at least one limitation to the value of at least one 

20 parameter such as a price, credit tenns. quantity, delivery date, catalog number, 
quality, or size. The one or more parameters characteristically describe the 
suggested transaction using a character string, a discrete value or a value range 
for a transaction attribute. 

The transaction server identifies at least three transaction profiles having 
25 overlapping limitations (i.e. Hmitations which are not mutually exclusive) where 
each transaction profile is submitted by a market party of a different market party 
class. 

Therefore, transaction profiles submitted by parties belonging to multiple 
market party classes are examined to identify transaction profiles having 
30 overlapping limitations. Matching transaction profiles include overlapping 
limitations and describe at least the common set of transaction characteristics 
acceptable to all parties involved In the transaction. Transaction information is. 
sent to each market party submitting a transaction profile identified as meeting 
the limitations of another transaction profile. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a transaction nfianagement system in 
accordance with an exemplary embodiment of the invention. 

FIG. 2 is a blocl< diagram of an exemplary transaction profile template. 
5 FIG, 3 is a block diagram of the transaction server interfacing to a graphic 

user interface (GUI) at the local processor in accordance with the exemplary 
embodiment. 

FIG. 4 is a block diagram of an exemplary transaction scenario of the 
transaction management system. 
10 FIG. 5 is a pictorial representation of a buyer transaction profile form as 

presented by a Web browser to the buyer in accordance with the exemplary 
transaction scenario and the exemplary embodiment of the invention. 

FIG. 6 is a pictorial representation of a seller transaction profile form as 
presented by a Web browser to the seller in accordance with the exemplary 
15 transaction scenario and the exemplary embodiment of the invention. 

FIG. 7 is a pictorial representation of a earner transaction profile forni as 
presented by a Web browser to the cannier in accordance with the exemplary 
transaction scenario and the exemplary embodiment of the invention. 

FIG. 8 is a block diagram of a storage architecture in accordance with the 
20 exemplary embodiment for buyer, seller, and transaction enabler trading 
scenario. 

FIG. 9 is a pictorial representation of transaction information as presented 
by a Web browser to the market party in accordance with the exemplary 
transaction scenario and the exemplary embodiment of the invention. 
25 FIG. 1 0 Is a flow chart of a method of managing transactions in 

accordance with the exemplary embodiment of the invention. 

FIG. 1 1 1s an illustration of a example of the use of indexing in 
accordance with the exemplary embodiment of the invention. 

FIG. 12 is flow chart of a method of identifying groups of transaction 
30 profiles submitted from a plurality of mart<et parties belonging to three or more 
market party classes In accordance with the exemplary embodiment of the 
invention. 

FIG, 1 3 Is flow chart of an exemplary optimization method. 
35 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



3 



wo 02/17194 



PCT/USOl/26158 



As described above, conventional electronic market techniques are 
severely limited by rigid and restrictive rules for representing a transaction 
request Including the need to specify definitive values for all parameters of the 
transaction. Further, conventional techniques provide only limited infomriation to 
5 the marl<et parties regarding the capabilities or desires of other market parties or 
provide such information effectively only in one direction typically only to the 
sellers. In addition, conventional systems only allow two parties to form a 
transaction preventing the optimal matching and formation of multiparty 
transactions. 

10 The present Invention overcomes these limitations and others by 

providing an efficient and flexible apparatus, system and method for managing 
electronic markets and transactions. FIG, 1 is block diagram of a transaction 
management system 100 in accordance with an exemplary embodiment of the 
invention. In the exemplary embodiment, market parties 102, which may be 

15 individuals or electronic trading systems, submit transaction profiles through local 
processors 104 (user terminals) connected to a communication network 106. A 
transaction server 112 identifies related transaction profiles, provides information 
to appropriate mari<et parties 102, commits market parties 102 to transactions 
and provides other services based on the content of the transaction profiles 

20 received. 

The transaction profiles include limitations to a suggested transaction 
acceptable to the market party 102 submitting the transaction profile. Since the 
limitations may allow for more than one value or transaction term, the transaction 
profile may describe more than one suggested transaction acceptable to the 

25 market party 1 02. The limitations may be values, character strings, or other 
symbols that limit or define transaction attributes such as transaction terms, 
market party names, locations, times, dates, product specifications, model 
numbers, catalog numbers, sizes, quantities or any other Information that may be 
used to describe a transaction. Further, a limitation may be a market party 

30 characteristic of a potential trading market party (102), Examples of market party 
characteristics that may be used as limitations to a transactions include aedit 
ratings, geographical locations, company size, number of offices, and amount of 
annual revenue. Other maricet party characteristics will readily occur to those 
skilled in the art. 

4 
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After receiving the transaction profiles, the transaction controller 108 
identifies at least three transaction profiles that have limitations meeting the other 
Identified transaction profiles. Each of the transaction profiles may be submitted 
by a market party belonging to a different market party class (also referred to as 
5 a market party classification). A limitation of a transaction profile meets another 
limitation of another transaction profile if the limitations of each transaction profile 
are not inconsistent with the other. Therefore, in context of a value limitation, one 
limitation meets another limitation if the two limitations are the same or if at least 
one value defined by one of the limitations is included in the description of the 
to other and no specified values are inconsistent with the other transaction profile 
description. 

Several groups of transaction profiles may be identified where each group 
includes at least two transaction profiles having overlapping transaction 
limitations. A single system can accept transaction profiles from a variety of 

IS industries and relating to a variety of subject matter and can identify the 

appropriate transaction profiles that match within a group. As discussed below in 
further detail, the transaction controller 108 accepts and processes transactions 
profiles having a wide variety of fomiats. The transaction profiles may describe 
search requests, expressions of interest to participate in a suggested transaction 

20 or group of transactions (soft match), or may be firm offers to enter into a 
transaction if the limitations are met. 

in the exemplary embodiment, the communication network 106 is a 
packet switched network, such at the Internet, that supports Transmission 
Control Protocol/Internet Protocol (TCP/IP), Hypertext Transmission Protocol 

25 (HTTP), and Hypertext Markup Language (HTIVIL). Although the transaction 

management system 100 utilizes the Internet and associated technologies, those 
skilled in the art will recognize the other types of communication techniques that 
may be used to facilitate the transaction management based on the teachings 
discussed below. For example, the communication network 106 may be an 

30 Ethernet network. Further, the communication network 106 may be any network 
or combination of networks suitable for peri'orming the functions described 
herein. Examples of other suitable data formats include Extensible IVIarkup 
Language (XIV1L), Standard Generalized Markup Language (SGML), serialized 
Java objects, and custom vector fomiats. The communication network 106 may 

35 include wire-line Internet networks as well as wireless communication systems 
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capable of transmitting the Information and messages between the local 
processors 104 and the transaction server 112. 

The transaction server 112 includes a transaction controller 108. a 
network Interface 1 10 and a database 1 14. As described below In further detaii, 
5 the network Interface 110 facilitates the transmission and reception of data and 
other messages through the communication network 106. The database 114 
provides a medium for storing Infonmation pertaining to the transaction profiles in 
addition to, as part of, or as an alternative to, RAM (Random Access Memory) 
storage and can be accessed by the transaction controller 108. The transaction 

10 controller 108 is connected to the communication network 106 through the 
network interface 110 and performs the transaction management functions. In 
the exemplary embodiment, the transaction server 112 is a computer such as a 
PC having dual Pentium III processors operating at a speed of at least 500 MHz 
and running a Windows NT® based operating system with 500 MB of RAM. 

, 15 Higher volume systems may require a transaction controller 108 utilizing a 

multiple CPU SUN Solaris box with several gigabytes of RAM. The transaction 
server 112, however, may be any type of computer processor, processor 
■ arrangement or processor combination suitable for implementing the functionality 
discussed herein. The network Interface 1 10 and the database 1 14 are shown as 

20 boxes with broken lines to illustrate that these functions may be implemented on 
other computers or processors connected to the transaction controller 108. 

The transaction controller 108 Is a computer program implemented in 
Pure Java on a computer running a Java Virtual Machine in the exemplary 
embodiment. The software used to facilitate the transaction controller 108 allows 

25 for parallel processing to run simultaneously on multiple processors or 
computers. Data synchronization is coordinated through the database 1 14. 
Transaction-profiles are received through the network interface 110, cached in 
Random Access Memory (RAM) (not shown), and compared to other transaction 
profiles stored in the database 114. Those skilled In the art will recognize the 

30 various other methods and anrangements for establishing a process or apparatus 
for perfonning the operations and calculations for the transaction management 
system 100. For example, the transaction controller 108 may be implemented in 
accordance with the Enterprise Java Bean (EJB) technology to allow 
management by a Web application server. 
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The network interface 110 facilitates communication between the 
transaction controller 108 and the communication networl< 106 and Is 
implemented using a Web servlet in addition to conventional Web server 
hardware and processes. Web servlets may run on Web servers available from 
5 Apache, Sun Netscape and IBM. No persistent data is stored in the Web servlet 
in the exemplary embodiment. As is known, Java servlets are software running 
on a Web server that process HTTP messages sent form the browser to the Web 
server (HTTP POSTs) and can be analogized to a Java applet running on Web 
browser. As discussed above, the box representing the network interface 110 is 

10 illustrated using dotted lines to indicate that the network interface 110 may be 
implemented as part of a transaction server 1 12 or as a separate apparatus. The 
functions of the network interface 110 may be implemented using other interface 
techniques such as those, for example, utilizing a Common Gateway Interface 
(CGI), IVIIcrosoft Active Server Pages and Java Server Pages for browser based 

15 trading and direct TCP/IP communications or methods such as Java RMl and 
CORBA for system-to-system trading. 

The database 114 maintains a persistent copy of all the transaction 
profiles submitted by the market parties 102 and of a corresponding storage 
stnjcture. Any one of several types of object or relational databases may be used 

20 in the exemplary embodiment. Examples of suitable databases Include object 
databases provided by Versant and relational databases provided by Microsoft 
and Oracle. Other types of database and storage techniques may be used to 
maintain the appropriate information and to provide access to the information by 
the transaction controller 108 including a naming or directory service. Access to 

25 an object database may be through the Object Database Management Group 
(ODMG) Application Program Interface or vendor specific interfaces and access 
to relational databases may be through JOBC, ODBC and other commercial and 
proprietary drivers. Multiple computers and storage mechanisms can be used to 
*' maintain the database 114 allowing the infomnation to be distributed across 

30 several machines. Redundant synchronized copies of the database may be 
maintained to provide reliability. 

The local processors 104 facilitate communication between the market . 
parties 102 and the transaction controller 108 through the network interface 110 
and the communication network 106. The local processors 104 may be any type 

35 of processor, microprocessor, computer, personal computer (PC), laptop 
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10 



computer, personal digital assistant (PDA) or processor arrangement or 
processor combination capable of performing the functions described below. In 
the exemplary embodiment, the local processor 104 Is a PC running a Windows 
2000® based operating system. The local processor104 Includes, or may be 
connected to, a communication interface such as a modem for communicating 
through the communication networl< 106. Those skilled in the art will recognize 
the various transmission media and techniques for linking the local processor 
104 to the communication system. Some examples of these techniques and 
devices include cable modems, analog modems. Digital Subscriber Line (DSL) 
modems, T1 lines, Ethernet connections, and any other digital or analog 
communication interface suitable for exchanging information between the local 
processor 1 034 and the communication system. 

In the exemplary embodiment, Web browser software running on the 
local processor 104 facilitates a graphic user interface (GUI) which allows the 
15 market party 1 02 to obtain information from, and submit information to. the 

communication network 1 06. Examples of suitable Web browser software include 
Netscape Navigator and iVlicrosoft Explorer. 

The local processor 104 includes at least one type of output device such 
as video monitor or display capable of presenting visual information of the GUI 
and may contain other output devices such as an audio speaker or printer. At 
least one input device allows the market party 102 to communicate information to 
the transaction controller 108. In the exemplary embodiment, the market party 
102 enters information through a keyboard and computer mouse into a 
transaction profile form presented as a Web page, Including an html <form> 
element, by the Web browser. Any suitable technique for entering Information, 
however, may be used. Examples of other input techniques Include using touch 
screens and entering Information through a microphone and speech-to-text 
software as well as automated trading by a computer program. Alternatively, If 
the market party has automated procurement or sales such as ERP software the 
30 communication with 1 02 may be software based (e.g. using data formats such as 
. XIVIL and technology such as RPC or messaging) and not Involve a display. 

In the exemplary embodiment, a transaction profile template in an XML 
format is accessible by the network Interface 1 10 and the transaction controller 
108. The network interface 1 10 transmits a Web page associated with a template 
to the tocal processor 104 In response to a request by the market party 102. The 
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Web page has a Hypertext Markup Language (HTML) format and includes a form 
with various fields that correspond to fields in the template. The market party 102 
enters Information Into designated fields within the Web page GUI to create a 
transaction profile. The transaction profile is transmitted to the.transaction server 
5 112 through the communication network 106 using a HTTP POST command and 
Transfer Control Protocol/Internet Protocol (TCP/IP) techniques. After receiving 
the transaction profiles, the network Interface 110 creates an XML message that 
includes the limitations described in the transaction profile. 

The transaction controller 108 parses the XML message and determines 

10 if any other transaction profiles meet the limitations of the transaction profile by 
comparing the limitations to the limitations of the other transaction profiles 
received from other market parties 102. If at least one other transaction profile 
meets the limitations of the received transaction profile (the limitations overlap), 
the transaction controller 108 determines that a match exists between the 

15 transaction profiles. 

Depending on the type of transaction profile, the transaction controller 
108 transmits a notification or other transaction Information to selected market 
parties 102, In the exemplary embodiment, a market party 102 submitting a 
transaction profile indicates the type of transaction profile that is submitted. The 

20 market party 102 may request a search, submit an interest expression that 

requests the identification for potential transaction participants that may be used 
to create a soft match, provide a firm offer to enter into a transaction or submit 
other types of transaction profiles. The data included In the transaction 
Information transmitted to a market party 102 is dependent on the type of 

25 ' transaction profile, the types of transaction profiles that have overlapping 

limitations and other factors. The transaction information may be transmitted to 
the market party 102 using HTTP techniques or may be forwarded using other 
communication techniques such as electronic mail. Electronic mall Is convenient 
for use when a match has been found to a transaction profile submitted at a time 

30 significantly earlier than the finding of the match since the party 102 submitting 
the earlier transaction profile may no longer have access to a Web browser at the 
time the match is identified. 

Each of the market parties 102 obtains a transaction profile torn from the 
transaction controller 108 through the communicatiori network 106. In the 

35 exemplary embodiment, the market party 1 02 submits a request for a transaction 

9 
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profile form by designating the appropriate Universal Resource Locator (URL) 
using the Web browser running on the local processor 104, Each type of 
transaction profile foon Is uniquely associated with an URL and the market party 
102 may obtain the desired transaction profile form by identifying the appropriate 
5 URL. A message formatted in accordance with TCP/IP is transmitted to the 
networl< interface 110. 

In response to the request for the transaction profile form, the networl< 
interface 110 transmits a Web page in accordance with Hypertext IVIarkup 
Language (HTML). Those sl<illed in the art will recognize that other types of 

10 marl<up languages or template languages, such as Cold Fusion, and 

communication techniques may be used to provide a Web page to the marl<et 
party 1 02, Although not yet widely accepted, XML methods are suitable for 
providing the required transfer of infomnation. The Web page provides a 
transaction profile form to the marl<et party 102 as a Graphic User Interface 

15 (GUI) displayed on the monitor or other visual display of the local processor 1 04. 
The transaction profile form Includes at least two attribute fields where 
each attribute field corresponds to a unique market party class. Examples of 
market party classes include buyers, sellers, carriers (shippers), insurers, 
undeoA/riters, financiers, and packagers. As those skilled in the art will recognize 

20 the various maricet parties can be defined in an almost unlimited way and the 
number and types of market party classes will depend on the particular industry, 
anticipated transactions and system 100, 

Therefore, a plurality of transaction profiles are received from a plurality of 
market parties 102 belonging to a plurality of market party dasses at a 

25 transaction controller 108 through a communication networi^ 106. The transaction 
controller 108 identifies at three transaction profiles that meet each other's 
limitations. The matched transaction profiles may Indicate different levels of 
market party 102 commitment Transaction information describing the Identified 
transaction profiles Is transmitted to the market parties 102 conresponding to the 

30 identified transaction profiles. Depending on the types of transaction profiles, the 
market parties 102 may receive Information such as the Identity of the other 
martlet parties 102 having overlapping interests, statistical infomiation, 
infonnation regarding the other transaction profile limitations. If the Identified 
transaction profiles are firm offers, the parties are committed to a transaction. 

35 Othenvise, the market parties 102 may use the transaction Infonnation to 
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continue pursuing an agreement with the parties to enter into a transaction. 
Combinations and adaptations of the above methods provide a sophisticated 
transaction management system 100 allowing a wide variety of transactions, 
reports and analysis. 
5 FIG. 2 Is a block diagram of an exemplary transaction profile template 

200. The transaction profile template 200 is a data structure implemented using 
XML and includes fields for receiving the Information entered by the market party 
102 in the transaction profile form. As explained above, the market party 102 
enters information Into a Web page displaying the transaction profile form when 

10 submitting the transaction profile. The completed transaction profile form Is 

transmitted through the communication network 106 and received by the network 
interface 110. The network interface 110 converts the HTML completed 
transaction profile form to an XML transaction profile fay extracting the 
appropriate information from the HTML transaction profile and placing it within 

15 the transaction profile template 200. Although various methods and techniques 
may be used to represent the transaction profile template 200, a language 
allowing the representations of sets of XML documents Is used in the exemplary 
embodiment and is referred to as the Extensible Profile Language (XPL). The 
XPL language may have any one of various structures and mles and the 

20 characteristics of the language relevant to the present invention are highlighted 
below. Those skilled in the art will recognize the various alteration, modifications 
and permutations that can be applied to the language discussed herein. 

In the exemplary embodiment, the transaction profile template 200 
includes a transaction profile classification 202 and a transaction profile 

25 description 204. The transaction profile classification 202 provides technical 
aspects of the transaction profile and includes a profile type indicator 206, an 
expiration date 208, and a market party designator 210. 

The profile type indicator 206 describes the type of profile that is being 
submitted by the market party 102 where each type is associated with a 

30 particular level commitment. The transaction profile may be a search request, a * 
request to identily potential market participants (soft match request), an offer, an 
auction submission or other transaction profile. The various transaction profiles 
are discussed In further detail below. 

The expiration date 208 limits the life of the transaction profile by 

35 indicating the time the transaction profile lapses. Although the expiration date 
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208 may not be critical for transaction profiles such as seardi requests, a market 
party 1 02 may desire that other types of transaction profiles have only a limited 
duration. For example, a market party 102 submitting an offer may only want the 
offer to stay open for a short time because of market vblatiiity. The market party 

5 1 02 submitting a reasonable offer at the time of submission may be seriously 
disadvantaged if the market changes substantially allowing an accepting market 
party 102 to unfairly reap rewards of an outstanding offer that has not lapsed. By 
limiting the duration of the transaction profiles, a market party 102 can reduce the 
risk of undesirable consequences due to market fluctuations. In addition, the 

10 expiration date 208 may be useful for other types of transaction profiles. A 
search will be stored until its expiration date 208 allowing the searching market 
party to receive notice of matching transaction profiles until the expiration date 
208. 

The market party designator 210 provides a classification of the market 

15 party 102 submitting the transaction request. Each market party designator 21 0 
is uniquely associated with a market party class. Therefore, examples of market 
party designators 210 include a buyer, seller, carrier, financier, insurer, 
undenwriter and packager designators. Depending on the particular market, the 
market party designator 210 may have different, additional or fewer potential 

20 designations to those mentioned. 

As desCTibed below, the transaction profile classification 202 may include 
other fields for describing the type of transaction profile, or other parameters 
related to the transaction profile other than a transaction tennn. Those skilled in 
the art will recognize that categorization of transaction profile classification 202 

25 indicators and transaction terms may be achieved in other ways. For example, 
the expiration date 208 may be considered to be a transaction term (In that it 
describes the ranges of allowed values for the time of the transaction) rather than 
a transaction profile classification 202. 

The transaction profile description 204 includes at least one field (212- 

30 220) for a transaction tern. In the exemplary transaction profile template 200, the 
transaction profile description 204 includes fields for transaction temis 
corresponding to price 212, quantity 214, a quaHty grade minimum 216, a quafity 
grade maximum 218 and a catalog number 220. Other transaction temrts that 
may be Included In a transaction profile template 200 Include parameters that 

35 relate to a product or service. For example, fields may be provided for a size. 
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style and color. The number and types of fields of a particular profile template 
200 will depend on the types of goods or services, traditions in the market, and 
other factors that will readily occur to those skilled in the art, 

A transaction term may be directed to a single market party class or 
5 multiple market party classes. For example, a quantity 214 transaction term 
submitted by a submitting market party 102 may affect the requirements of more 
than one market party 102 of the transaction where the affected market parties 
102 belong to different market party classes. If the submitting market party 102 is 
seller (404) offering a product at a particular quantity and the transaction involves 
10 a carrier (406) and a buyer (402), the quantity term pertains to each of the 
market parties' 102 requirements. The buyer (402) must be willing to buy the 
product in the particular quantity and the canrier (406) must be willing to ship the. 
particular quantity that the seller (404) will sell and the buyer (402) will buy. Any 
transaction term may correspond to any number of market party classes. If an 
• 15 insurer (406) is involved in the transaction, for example, the quantity tenm will 
likely affect the requirement of the insurer (406). The willingness of the insurer 
(406) to enter into an agreement for a particular fee will depend on the potential 
for loss, the value of the total product shipped and therefore, the quantity* 

A transaction term may be directed to single market party class. For 
20 example, a quality term may be relevant to a buyer (402) and seller (404) and will 
not change the requirements of a carrier (406). 

Each transaction temi may be represented by a single value, a wild card, 
or a range of values. The quality grade minimum 216 and quality grade maximum 
21 8 provide an example of a transaction term having a range of values 
25 con-esponding to a specification transaction tenn. For this exemplary transaction 
tenn, the value contained in quality grade minimum 216 field and the value in the 
quality grade maximum 218 field define a range of values corresponding to the 
quality grade. Since quality grades are typically represented by a discrete value, 
the transaction term range defines a finite set of possible values between the 
30 maximum and the minimum value. For other types of transaction terms, however, 
the defined range may represent an Infinite number of values. 

A catalog number field 220 provides a location for specifying a particular 
catalog number 220 that describes the item by a specific identifier. 

A single value transaction term such as the price 212 term, catalog 
35 number 220 or the quantity 214 term may be defined with a wild card symbol 
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indicating that any value is acceptable to the market party 102 submitting the 
transaction profile. 

Other types of specifications for a parameter include enumeration of 
acceptable values, key words or expressions which must appear In a matching 
5 text parameter. Further, some indication of preference between stored values 
may be provided. 

In the exemplary embodiment, a unique transaction profile form 
associated with a market party class. Accordingly, a buyer transaction profile 
template 200 Is used to create a buyer transaction form which is submitted only 
10 to market parties belonging to the buyer class. Sellers, carriers and other receive 
transaction profiles forms associated with their market party class. 

The data represented in a transaction profile may have a hierarchical 
stmcture using XIVIL, This allows groups of related parameters to be grouped 
both for clarity and to allow them to be wild carded in a single operation. An 
15 exemplary hierarchical structure of a transaction profile is shown In Appendix L 
The transaction profile relates to a market party 102 wishing to sell a black BMW 
having two alrbags and antilock brakes where the safety features have been 
grouped. 

Appendix II illustrates an exemplary hierarchical structure of a transaction 

20 profile relating to a buyer looking for a black or blue BMW but unconcerned with 
safety features. If both transaction profiles described in Appendices I and II were 
submitted, a successful match would occur. As shown in Appendix II, safety 
features have been grouped as children elements of <safety-features> and are 
thus wild-carded with a single <xpl:any-element-list>. 

25 In the exemplary embodiment, the transaction management system 100 

accepts and processes several different types of transaction profiles. Each 
transaction profile indicates a level of intended commitment to a suggested 
transaction by a transaction profile type indicator 206. As discussed above, the 
profile type indicator 206 provides a description of the type of transaction profile 

30 that Is intended by the market party 102 submitting the transaction profile. For 
example, a transaction profile having a transaction profile type indicator 206 
designating the transaction profile as a search request indicates that the market 
party 102 commitment of the market party 102 submitting the transaction profile 
Is limited to only receiving Information relating to the suggested transaction 

35 described In the transaction profile. 
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A search allows a market party 102 to identify market parties 102 having 
particular interests as Indicated by the transaction terms of the search request. In 
the exemplary embodiment, search requests are submitted anonymously and 
matched to other transaction profiles. Search results are only reported to the 
5 market party 1 02 submitting the search request and are not provided to market 
parties 102 submitting other matching transaction profiles to the search request. 

The transaction controller 108 identifies these market parties 102 by the 
transaction profiles they submit. Accordingly, a search request may result in 
several identified martlet parties 102 that have submitted different types of 
10 transaction profiles. As explained above, transaction terms may be described as 
ranges or may include wild cards con^esponding to any value or partial flexibility 
such as a range or enumeration of acceptable values allowing the market party 
102 submitting a search request to limit the breadth of the search. Accordingly, a 
search may result in the Identification of several market parties 102 submitting 
15 different types of transaction profiles with different transaction terms. 

An expression of interest (soft match request) allows market parties 102 
to identify potential trading partners by advertising their interest in entering Into a 
particular category of transactions without firm commitment The results of a soft 
match provide the market parties 102 with identities of the market parties 102 
20 meeting the request criteria (transaction profile), at least some details of the 
other identified transaction profiles, explore alternate transaction terms and 
progress efficiently to a next level of negotiation with the market party 102" having 
the most attractive transaction terms. Negotiations may take the form of 
traditional techniques such as telephone or email or may continue with 
25 subsequent transaction profiles. Market parties 1 02 may observe the market by 
tracking the changes in matching transaction profiles and noting trends in the 
number of matching transaction profiles and the transaction terms included in 
matching transaction profiles. 

A firm offer describes a transaction to which the submitting market party 
30 102 is willing to be legally bound. The submitting market party 102 expects to be 
bound to a transaction if the firm offer of another market party 102 matches the 
transaction profile. The transaction controller 108 clears the transaction after 
offers are matched without any additional Input or instruction from the submitting 
market parties 102. 

15 
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Combinations and modifications to the core transaction profiles discussed 
above allow a wide variety of market negotiations and exchange of infomnation. 
Examples of other transaction profiles include Auctions, Dutch auctions, reverse 
auctions, reverse Dutch auctions, and Request For Quotations (RFQs). 
5 English Auctions are launched by a seller and allow interested buyers to 

propose ascending prices until the highest bidder (or combination of highest 
bidders when bids are allowed on partial quantities) Is awarded the goods in a 
predetermined time. As an example of how the different levels of commitment 
can be applied to modeling complex market mechanisms, the English Auction 

10 may be implemented as an expression of interest which is periodically replaced 
with an expression of interest with higher minimum price and which at the end of 
the auction is repJaced with a finri offer which then clears Immediately with the 
highest bids (bids being represented by firm offers which are controlled to clear 
with the auction only by an auction number parameter which Is introduced Into all 

15 transaction profiles associated with the auction.) 

Reverse auctions are launched by the buyer and allow Interested sellers 
to take turns to propose descending price until the lowest bidder (or combination 
of bidders when bids are allowed on partial quantities) is awarded a supply 
contract in a predetermined time. 

20 In Dutch Auctions, which are launched by the seller 404, the market 

maker periodically calls descending prices until a buyer 402 (or a number of 
buyers when bids are allowed on partial quantities) agrees to purchase the goods 
offered at the price called. As a further example of how the different levels of 
commitment can be applied to modeling complex market mechanisms* the Dutch 

25 Auction may be implemented as a firm offer which is periodically replaced with a 
firm offer with descending prices. 

A market party 102, such as a seller 404, inherently submits a request- 
for-quotation (RFQ) when transmitting an expression of interest (soft match) 
transaction profile. Other market parties 102 may learn of tlie expression of 

30 interest through a search request or through automatic notification upon overlap 
with their own stored search or soft match request and submit the quotation in 
the fonn of a finn offer limited to the particular market party 102 submitting the 
soft match transaction profile. 

If the transaction profile is a search request, thQ transaction controller 108 

35 fonvards transaction information related to market parties 102 submitting 
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transaction profiles liaving overlapping limitations to the searcher. The 
transaction information includes the identity of market parties 102 submitting 
requests for soft matches and market parties 102 providing firm offers. The 
reporting logic will however not report the existence of one search to another 
5 overlapping search. 

In the exemplary embodiment, anonymity is controlled at the market level 
by the inclusion or exclusion of the market party 102 from the results page. The 
inclusion of party information in the transaction profile also depends on whether 
the identity of the market party 102 is one of the parameters which is a 

10 transaction term and examined to determine if a match exists. The inclusion of 
the parties' Identity In the transaction profile may be desirable, for example, 
where the market party 102 submitting a transaction profile indicates that only 
selected market parties 102 are acceptable for entering Into a transaction by 
specifying the names, geographical location, credit rating, or other criteria of the 

15 preferred market party 1 02 for a transaction. Other suitable methods for 
controlling anonymity include submitting a transaction profile that indicates 
whether the identity of the submitter can be revealed to other market parties 102 
or by including only a pseudorandom handle representing the user. The identity 
of the submitter may be omitted for other reasons, however. 

20 Appendices III and IV illustrate exemplary buyer and seller transaction 

profiles useful for discussing a matching criteria based on the detailed 
characteristics of the market parties 102. As shown in Appendix III, the buyer 
transaction profile specified by a fictitious company, "Electronics Procurement 
Inc.," Indicates the resistors required, the identity of the buyer and specifies the 

25 seller as a wild card indicating that the buyer will work with any seller. Appendix 
IV provides an exemplary transaction profile submitted by a seller wishing to sell 
lots of 1000 and 10,000 and that is only willing to enter into a transaction with a 
buyer in California. 

By Including details of buyer 402 and seller 404 as parameters of the 

30 transaction, the same wild cards which are used to match product parameters 
may be used by buyers and sellers to select the specific partners they will work 
with by name, or the type of trading partner they will accept based on, for 
example, geography or credit rating. Appendix V Illustrates an exemplary 
resulting transaction profile of a match between the buyer and seller transaction 

35 profiles. The intersection specifies a specific value for quantity, buyer and seller 
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, and can be used as record of a resulting contract between the two market parties 
102. Another example Includes further parameters describing the product and 
transaction terms. 

FIG. 3 is a block diagram of the transaction server 1 12 interfacing to a 
5 graphic user interface (GUI) 302 at the local processor 1 04 in accordance with 
the exemplary embodiment In response to a request for a transaction profile 
form, the web server within the network Interface 110 retrieves a transaction 
profile form 306 stored in HTML format either on the network interface 1 10 or In 
storage accessible to the network interface 110. The Web server transmits the 

10 transaction profile form to the local processor 104 where It is displayed to the 
market party 102 through a GUI 302, The transaction profile form 306 includes 
fields that correspond to the associated transaction profile template 200. 
Accordingly, the transaction profile form 306 solicits information corresponding to 
the fields within the transaction profile template 200 and provides the market 

15 party 102 with a vehicle for providing the transaction profile since the completed 
transaction form 310 includes the information of the transaction profile. 

The GUI 302 may be any type of suitable user interface for receiving and. 
entering information. In the exemplary embodiment, the GUI 302 includes the 
Web browser and an electronic mail (e-mail) interi'ace. Other GUI 302 

20 an^angement will be readily apparent to those skilled In the art. 

The market party 102 enters the appropriate infonnation to express the 
suggested transaction to fonn a completed transaction profile fomi 310 . The 
completed transaction profile form 310 is infonnation to be included in the 
transaction profile in a HTTP POST fonrnat that Is transmitted to the network 

25 interface 110 tiirough the communication network 106. The web servlet 304 
parses the transaction profile (completed transaction profile form 310), extracts 
the appropriate information from the completed transaction profile fonn 310, and 
Inserts the information into an XML template 312 to form an XML formatted 
transaction profile which in the exemplary embodiment may include XPL wild 

30 cards. The XML formatted transaction profile is transmitted to the transaction 
controller 108. 

A matching engine 314 in the transaction controller 108 retrieves other 
transaction profiles stored In the database 1 14 in order to compare the various 
transaction profiles and to Identify at least one other transaction profile having 
35 limitations that meet the incoming transaction profile. The transaction profiles are 
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indexed in memory to allow efficient elimination of many of the transaction 
profiles tiiat will not matcli the incoming transaction profile. As described below in 
further detail, the matching engine 314 uses Indexes to nan^ow the set potential 
matching transactions to a smaller subset of potential matching transaction 
5 profiles to promote efficient matching techniques. Various methods, however, 
may be used to match the transaction profiles. 

In the exemplary embodiment, the matching engine 314 invokes a 
reporting engine 316 and a clearing engine 318 based on the results of any 
identified matches. If the matching engine 314 determines that two or more firm 

10 offers have matching transaction criteria (overlapping limitations), the matching 
engine 314 forwards the appropriate information to the clearing engine 318. The 
clearing engine 318 is responsible for removing sets of matching finm offers from 
the market and passing on a record of the consummated transaction to a 
fulfillment engine 320, The fulfillment engine 320 is a marketplace system which 

15 tracks the execution of a contract when market parties 102 have agreed on an 
acceptable transaction. 

In the exemplary embodiment, the clearing engine 318 performs 
resolution of overlaps, prioritization and clearing. An agreed transaction must 
have a specific value for every parameter. If both market parties 102 had 

20 flexibility in some parameter, the intersection may still be flexible. For example, if 
the seller offered delivery dates between 12"" and 15^ and the buyer specified a 
delivery date between 10*^ and 14*^ then any date between 12^^ and 14^ would be 
acceptable to both market parties 1 02 and this range wiil be specified in the 
resultant transaction profile. The clearing engine 318 will replace any such range 

25 with a specific value. Typically, the market provider will specify (e.g. using an 
attribute in the XML template) whether flexibility in a given parameter should be 
rounded up or down. 

Matching is prompted by a newly submitted transaction profile and the 
new transaction profile may match with more than one pending transaction 

30 profile. The clearing engine 318 organizes ail the possible matches in order of 
priority for clearing. In the exemplary embodiment, the market provider (or an 
individual user via a transaction profile) can specify a parameter or more than 
one parameter In order of precedence (e.g. price or submission date) according 
to which potential matches are prioritized for matching. 
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The clearing engine 318 clears transactions in accordance with the 
matching transaction profiles. Pairs of requests are either removed or their 
quantity available is mutually reduced according to the prioritization until the new 
request leading to the match is totally cleared or there is nothing left with which to 
5 clear. 

The reporting engine 316 produces a resulting transaction profile based 
on all transaction profiles of group Identified as having overlapping limitations. In 
the exemplary embodiment, the resulting transaction profile is fomnatted in 
accordance with XML and contains information including the identity of the 

10 market parties 102 that have submitted matching transaction profiles and the 
transaction attributes from the transaction profiles including transaction terms 
such as price, quantity, catalog numbers, locations, and colors. 

The resulting transaction profile is transmitted in an XML fomnat to the 
networt< interface 110, In the exemplary embodiment, the Web servlet 304 uses 

15 an XSLT script 308 to render XML into an HTML page and provides a visual 
display of the results by showing the results, for example, in tabular form. As is 
known. XSLT (extensible style sheet language transformations) is a language 
that provides a flexible process for the transfomnations of XML documents to 
HTML and other languages or types of XML documents. The network Interface 

20 110 notifies the market parties 102 in a way appropriate to the choices of the 
market provider and of the specific market party 102 to be notified. In the 
exemplary embodiment, the market party 102 that submitted the last transaction 
profile that resulted in a transaction match is notified using an html results screen 
in a results page 322. An HTML web page 322 is appropriate since this last 

25 entering market party 102 Is on line and has an open bnDWser. Other matching 
market parties 102 are notified by a results e-mail 324. The resulting transaction 
profile (322) formatted in accordance with HTML Is transmitted through the 
Internet to the local processor 104. The GUI 302 on the web bnDwser displays the 
resulting transaction profile as the results page 322 to the market party 102, 

30 Other forms of notification Include messaging to a backend system or integration 
with, for example, Wireless Access Protocol (WAP) applications. 

An enterprise system 326 provides backend procurement and sales 
services for the transaction management system 100. The enterprise system 326 
is an Enterprise Resource Planning (ERP) system that can integrate to the 
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system 100. Examples of suitable ERP systems include systems available from 
SAP, Peoplesoft. Oracle. Baan and J.D, Edwards. 

FIG. 4 Is a block diagram illustrating a transaction scenario in accordance 
with the exemplary embodiment of the Invention where the market parties 102 

5 include buyers 402, sellers 404, and transaction enablers 406. As discussed 
above, the market parties 102 may be any type of potential participants in a 
transaction. Although for illustrative purposes, FIG. 4 relates to an example of a 
commercial transaction that includes at least one buyer 402 and one seller 404. 
other types of transactions and trading scenarios can be managed by the 

10 transaction management system 100. For example, a reinsurance transaction 
may include market parties 102 categorized as assume and cede and an Interest 
rate swaps transaction may involve parties which pay-fixed and receive-fixed. In 
the exemplary embodiment, the transaction controller 108 can process and 
evaluate transaction profiles related to several types of transactions. Industries, 

15 products and services. For purposes of the example discussed with reference to 
FIG. 4, however, the buyers 402, sellers 404 and transaction enablers 406 are 
potential participants in a commercial market of gasoline. 

During setup and customization procedures, the transaction profile 
template 200 for each type of market party 102 within each market is created in 

20 accordance with the particular market. Each transaction profile template 200 will 
have a general form of the transaction profile corresponding to the type of market 
party 102 submitting the transaction profile, The transaction profile template 200 
has "holes" for transaction attribute values such as price, quantity and quality 
which vary from profile to profile. The market party 102 submitting the transaction 

25 profile provides information to complete the form to create the transaction profile. 
Preferably, the transaction profile template 200 follows any formal XML Data 
Type Document (DTD) or Schema accepted by the particular market. 

A buyer 402 accesses the transaction management system 100, by 
requesting a buyer transaction profile fomn through the local processor 104 and 

30 the communication network 1 06. In the exemplary embodiment, the buyer 402 
requests the appropriate transaction form by accessing the URL of the form 
through the home Web page of the transaction management service provider 
The network interface 110 provides a transaction profile form as an HTML Web 
page using HTTP techniques. In the exemplary trading scenario, a separate 

35 transaction form is provided to the buyer 402, seller 404 and the carrier 
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(transaction enabter) 406 where each fomn utilizes a different transaction profile 
template 200. 

FIG, 5 is a pictorial representation of a buyer transaction profile form 
(buyer form) 500 in accordance with the exemplary embodiment of the invention, 
5 The buyer form includes instruction text 502 including information potentially 
helpful to the buyer 402 when completing the buyer form 500. A profile type field 
504 includes a space for entering the type of transaction that the buyer 402 
intends to submit. In the exemplary embodiment, the buyer 402 may chose 
between two status options that are accessible through a pull-down menu 

10 including a search (browse) or soft match (expression of interest). A maximum 
price field 506 allows the buyer 402 to enter a maximum price the buyer 402 is 
willing to pay per ban^el of gasoline. In the present example, the buyer 
transaction profile form 500 is hard valued to zero as the minimum price. The 
buyer 402 enters the appropriate minimum and maximum values for a quantity 

15 range 508. A minlmum quantity field 510 allows the buyer 402 to enter any 
integer denoting the minimum number of barrels the buyer 402 is willing to buy. 
The maximum quantity field 512 provides an entry location for the maximum 
number of barrels the buyer 402 wishes to obtain. The delivery date field 514 
includes two fields for defining a range of dates that the buyer 402 would 

20 consider for delivery of the gasoline. A grade field 516 allows the buyer 402 to 
enter the preferred grade of oil to be purchased. In the exemplary embodiment, 
"the buyer 402 rfiay choose the grades by choosing the appropriate option in a 
pull-down menu. The pull-down menu provides a wild card option by allowing the 
buyer 402 to choose all grades of oil. In the exemplary scenario, the buyer 402 

25 may enter tolerance values for defining the gasoline. For example, an RVP field 
518 allows the buyer 402 to specify a range for the Residual Vapor Pressure 
(RVP) of the gasoline. An oxygenates section 520 allows the buyer 402 to enter 
the desired tolerance values for MTBE and ethanol as a percentage of volume of 
the gasoline. A shipment location field 522 allows a buyer 402 to enter the 

30 location to which the oil should be delivered. In the exemplary embodiment, a 
state may be designated using a pull-down menu and a zip code can be entered 
manually by the buyer 402, A transaction information request field 524 allows 
the buyer 402 to request the number of days for which the transaction profile will 
be stored In the transaction server 112. The buyer 402 will receive updates 

35 reporting any new matching transaction profiles submitted during the pending 
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period of the transaction profile. In addition, an e-mail address field 526 allows 
the buyer 402 to designate an e-mail address that will receive the transaction 
information. A submit button 528 allows the buyer 402 to submit the transaction 
profile form to the network interface 110 when the transaction profile form has 
5 been completed. The submit button 528 Is Implemented In accordance with 
known internet techniques. 

FIG. 6 Is a pictorial representation of a seller transaction profile form 
(seller fonm) 600 implemented as a Web page. The seller form 600 includes 
instruction text 602 including information potentially helpful to the seller 404 when 

10 completing the seller form 600. A profile type field 604 includes a space for 
entering the type of transaction that the seller 404 intends to submit. In the 
exemplary embodiment, the seller 404 may chose between two status options 
that are accessible through a pulldown menu including a search request and a 
soft match (expression of interest). A minimum price field 608 allows the seller 

15 4Q4 to enter a minimum price the seller 404 is willing to receive per barrel of 
gasoline. The seller 404 enters the appropriate minimum and maximum values 
for a quantity range 608. A minimum quantity field 610 allows the seller 404 to 
enter any integer denoting the minimum number of barrels the seller 404 is 
willing to sell In a transaction. The maximum quantity field 612 provides an entry 

20 location for the maximum number of ban-els the seller 404 wishes to obtain. The 
delivery date field 614 includes two fields for defining a range of dates that the 
seller 404 is presenting for delivery of the gasoline. A grade field 616 allows the 
seller 404 to enter the preferred grade of oil to be purchased.' In the exemplary 
embodiment, the seller 404 may choose the grades by choosing the appropriate 

25 option in a pull-down menu. The pulKdown menu provides a wild card option by 
allowing the seller 404 to choose all grades of oil. In the exemplary scenario, the 
seller 404 may enter tolerance values for defining the gasoline. For example, an 
RVP field 616 allows the seller 404 to specify a range for the Residual Vapor 
Pressure (RVP) of the gasoline. An oxygenates section 620 allows the seller 404 

30 to enter the desired tolerance values for MTBE and ethanol as a percentage of 
volume of the gasoline. A shipfient location field 622 allows a buyer 402 to enter 
the location to which the oil should be delivered. In the exemplary embodiment, 
a state may be designated using a pull-down menu and a zip code can be 
entered manually by the buyer 402. A transaction Information request field 624 

35 allows the seller 404 to request the number of days for which updates will be 
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received. In addition, an e-mail address field 626 allows the seller 404 to 
designate an e-mail address that will receive the transaction infonnation. A 
submit button 628 allows the seller 404 to submit the transaction profile form to 
the networi< interface 110 when the transaction profile form has been completed. 
5 The submit button 628 is implemented in accordance with known internet 
techniques. 

Appendix VI includes an exemplary XML document suitable for 
implementing a transaction profile template (tpt) 200 consistent with the seller 
transaction profile form 600. Selections from the appendix are reproduced below 
10 and integrated with the following discussion. 

The following element is the root element for the XML document to be 
instantiated by the template. It includes a definition of the xpl and tpt 
namespaces as required by the XML Namespace standard. 

15 <ga2-sale xmlna:xpla"http://www. tradeiam.com" 

xmlns : tpta "http i //www. tradeum. com" > 

The following demonstrates a template command generating a 'Valid-tiir 
time for the transaction profile with a standard forniat (e.g. with children for year. 
20 month, day, hour, minute and second) and is based on the current time and 
offsets provided by the http submit. For example, the transaction information 
request field 624 may be given a reserved html name telling the tpt processor 
that the value provided Is an offset to be used to calculate the correct expiry 
date. 

25 

<tpt:validtill/> 

The following XML element groups the details of the parties Including the 
buyer 402 and seller 404 of the transaction. 

30 

<parties> 

<buyer> 



The following template command will generate details of the submitter (In 
35 this case acting as buyer 402). In the exemplary embodiment, the details are 
retrieved from the database 1 14 based on the logon name as well as information 

24; 
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generated by the network controller such as the network controller's IP address, 
a local handle for the user or a random request ID. 

< tpt I orlglnator> 
5 </tpt!originafcor> 



The following line marks the level of commitment which the market party 
102 is expressing to the transaction profile. The command tptinserttext is a 
template command which represents a value to be filled in by the submitting 
10 party in the form in this case in field 604 which is assumed to have been given 
html field name "status". 

<status><tpt : inserttext 

fieldonstatus"/></status> 
15 </buy©r> 

Given that this transaction profile template 200 is for buyers 402, details 
of the sellers 404 are hard coded to be a wild card. In other words the buyer 402 
will work with any seller 404 that matches the other requirements. 

20 

<xpl : any__elemant/> 
</partles> 

The quantity Is expressed as an XPL range element where the minimum 
25 and maximum are filled In by the tpt: in-attribute template command from the 
fields 610 and 612. 

<quantity> 

<xpl: range minactpt :ininguantity" 
30 inax=»«tpt:inaxquantity" praf era"up"/> 
< /quant ity> 

Continuing with the exemplary template and form, the price element is a 
range which the buyer 402 has a hard-coded minimum of "0" In the template and 
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a maximum to "be filled in from field 606. A preferred attribute is used to indicate 
the direction In whicli any price range should be resolved upon clearing, 

<prica> 

5 <xpl: range inina"0" maxa^tpt: price" 

pr Q f er a " down " / > 

</price> 
<source> 

<xpl : anyeleiaentlist/> 
10 </3ource> 

<destination> 
<state> 

<tpt:insertt6xt fielda''state"> 

15 An error message can be generated using the template convention 

below. This template convention allows an error message to be specified as a 
child of tptlnsertext. If no value is entered for the relevant field, the template will 
not be instantiated and the ennor will be returned to the user. 

<tpt terror texte"<h2>Flease 
specify your state. Press the Back button to 
continue • </h2>"/> 

</tpt : inserttext> 
</state> 
<zip> 

<tpt:inserttext fielda"zip"> 

<tpt: error texts "<h2>Pleas6 
specify your zip code. Press the Back button to 
continue. </h2>"/> 

</tptsinserttext> 
</zip> 
</destination> 
<delivery> 
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The "xplrdaterange" command represents a range of times between 
the first and second <date> children as illustrated in Appendix VI, Other 
exemplary ranges are shown in Appendix VI. 

FIG. 7 is a pictorial representation of the.carrier transaction profile form 

5 (carrier form) 700. The carrier form 700 includes instruction text 702 including 
information potentially helpful to the carrier (406) when completing the carrier 
form 700. A profile type field 704 includes a space for entering the type of 
transaction that the canier (406) intends to submit. In the exemplary 
embodiment, the carrier (406) may chose between two status options that are 

10 accessible through a pull-down menu including a search and an expression of 
interest. A shipping cost field 706 allows the seller 404 to enter a minimum price 
the carrier (406) is willing to receive for shipping each barrel of gasoline. The 
can-ier (406) enters the appropriate minimum and maximum values for a quantity 
range 708. A minimum quantity field 710 allows the carrier (406) to enter any 

15 integer denoting the minimum number of ban-els the earner (406) is willing to ship 
in a single transaction. The maximum quantity field 712 provides an entry 
location for the maximum number of barrels the carrier (406) wishes to ship in a 
transaction. The delivery date field 714 Includes two fields for defining a range of 
dates that the carrier (406) is presenting for shipment of the gasoline. A grade 

20 field 71 6 allows the carrier (406) to enter the preferred grade of oil to be shipped. 
In the exemplary embodiment, the carrier (406) may choose the grades by 
choosing the appropriate option in a pull-down menu. The pull-down menu 
provides a wild card option by allowing the carrier (406) to choose ail grades of 
oil. A shipping duration field 718 allows the canrier (406) to enter shipping 

25 duration range in days. The seller 404 enters one or more locations that the 
carrier (406) is willing to acquire the oil by choosing one or more options from a 
pull down menu in the pickup location field 720, The delivery location Is indicated 
in the delivery location field 722. A transaction Information request field 724 
allows the caMer (406) to request the number of days for which updates will be 

30 received. The e-mail address field 726 allows the seller 404 to designate an e- 
mall address that will receive the transaction information. A submit button 728 
allows the carrier (406) to submit the transaction profile form to the network 
interface 110 when the transaction profile form 200 has been completed. 

The network Interface 110 extracts the appropriate information form each 

35 field In each transaction profile (500. 600, 700) received and enters the 
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information into a transaction template corresponding to the type of transaction 
profile. As discussed above, transaction profile templates 200 are created in 
accordance with XML techniques during the initialization procedure used to 
create XML transaction profiles. Each transaction profile is received in an HTTP 

5 POST format and converted into an XML fomiat by inserting information 

extracted from the HTML transaction profile into an appropriate XML template. 
Therefore, information received in the fields of the buyer form 500 are inserted 
into the appropriate fields of a buyer template to form a buyer transaction profile. 
Infonmation contained within the HTML seller forni 600 is placed within an XML 

10 template to create an XML seller transaction profile. A carrier XML transaction 
profile is fonfned using the HTML carrier form 700. 

The XML transaction forms are received at the transaction controller 108. 
The transaction controller 108 identifies combinations of buyers 402, seller 404 
and carrier profiles with non-empty three way intersection. In the exemplary 

15 embodiment, each incoming transaction profile is compared to all stored 

transaction profiles to identify non-empty intersections. The transaction controller 
108 preferably indexes the stored transaction profiles to allow for efficient and 
rapid elimination of non-matching transaction profiles and individual comparison 
of potential matching transaction profiles to identity the transaction profiles 

20 having limitations meeting the limitations of the incoming transaction profile. 

FIG. 8 is a block diagram of a storage architecture in accordance with the 
exemplary embodiment for a buyer 402, seller 404, and transaction enabler 
trading scenario. In the exemplary scenario of a three way match, the transaction 
controller 108 preferably stores not only submitted transaction profiles but also 

25 two-way matches already calculated so that the three way match may be 

computed imhiediateiy when the third party enters. Buyer transaction profiles 802 
are matched with seller transaction profiles 804 and stored as buyer-seller 
combination transaction profiles 806. Buyer transaction profiles 802 are matched 
with carrier transaction profiles 808 and stored as buyer-carrier combination 

30 transaction profiles 810. Canrier transaction profiles 808 are matched with seller 
transaction profiles 804 and stored as seller-carrier combination transaction 
profiles 812. The matched combinations of all three parties are stored as buyer- 
seller-carrier combination transaction profiles 814. Preferably, the system stores 
the single profiles and two and three way matches in a directed acyclic graph 
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representing the semi-lattice (in algebraic terms) of the transaction profiles and 
their intersections with the partial order relation of set inclusion. 

The arrows In FIG. 8 point from a transaction profile to a subset of that 
transaction profile representing its intersection with a compatible transaction 
5 profile from a different party. The buyer-seiier-carrier combination transaction 
profiles 814 (three way intersection or, more generally, an intersection between 
all relevant party roles) need not be stored and can be directly reported to the 
appropriate market parties 102. 

For each computed intersection the transaction controller 108 will call 
10 reporting logic which will decide which market parties 102 to notify. In the 

exemplary embodiment, an intersection between a search and a soft match will 
be notified to the soft match only. The intersections will be reported in XML and 
still containing special wild card elements if the overlap still has flexibility 
remaining. The matches are converted into an appropriate format such as an 
15 HTML table, for example, using the Extensible Styling Language Transformation 
(XSLT). 

FIG. 9 is a pictorial representation of a resulting transaction profile 900 
(transaction information) as presented by a Web browser to the market party 102 
in accordance with the exemplary transaction scenario and the exemplary 

20 embodiment of the invention. A transaction attribute may be described in the 
resulting transaction profile 900 as a single value or a plurality of values. For 
example, a resulting transaction profile 900 resulting from the intersection of two 
or more expressions of interest (soft match) may Include one or more transaction 
attributes represented by ranges, wild cards or partial wild cards. 

25 The exemplary resulting transaction profile represented as 900 in FIG. 9 

corresponds to a soft match scenario. The resulting transaction profile includes • 
transaction Infonmation 918 con^espondtng to the transaction profiles submitted 
by three market parties 102; a buyer 402. a seller 404, and a carrier (406). The 
type of transaction profile submitted by each market party 102 is displayed in a 

30 status field 902 - 906. The text string "proposal" In the column indicates that 
each transaction profile was an expression of interest to enter into a suggested 
transaction. The quantity field 908 provides a description of the overiapping 
range of quantity values submitted by the nlari<et parties 102. In the example, 
1000 to 10000 gallons is included within all the specified acceptable ranges 

35 within the transaction profiles submitted by all of the market parties 102 within the 
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identified group. The price field 910 indicates the acceptable values of prices that 
the seller 404. and buyer 402 are willing to entertain. In the example, the buyer 
402 and seller 404 must continue to another of level of negotiations before either 
party Is committed to a price or quantity. The marl<et parties 102 may continue to 

5 use the transaction management system 100 to agree on a value by submitting 
subsequent transaction profiles which may be firm offers of more restrictive 
expression of interest. The mari<et parties 102 may continue to negotiate using 
other methods such as email, facsimile, or conversation. 

The origin location is displayed In the origin field 912 and the destination 

10 of the delivery of the gasoline is shown in the destination field 914. The delivery 
date 916 indicates a range of acceptable delivery dates. The market parties 102 
may continue to negotiate to more narrowly define the delivery dates or agree 
that the delivery date within the range specified is acceptable in a cleared 
transaction. 

15 FIG. 1 0 is a flow chart of a method of managing transactions in 

accordance with the exemplary embodiment of the invention. At step 1002. the 
transaction server 112 receives a request for a transaction profile form. The 
networI< interface 1 10 receives a request for a transaction profile form. As 
described above, the market party 102 submits a request for the transaction 

20 profile form by indicating the appropriate URL through a Web browser. The URL 
uniquely indicates to the network interface 1 1 0 the type of transaction profile the 
market party 102 requires. 

At step 1004, the network interface 1 10 transmits a Web page to the local 
processor 104. The Web page is a transaction profile fomn having at least one 

25 transaction that the market party 1 02 can modtiy or use to describe a transaction 
term or other parameter. 

The transaction server 112 receives the transaction profile at step 1006. 
The network interface 1 10 receives the completed transaction profile fomn 300 
from the market party 102 through the communication network 106 in an HTML 

30 format 

The network interface 110 converts the transaction profile into an XML 
format at step 1006 by instantiating a transaction profile template 200. The 
values and wild cards in the transaction profile originate in some combination of 
the values submitted in the form and values hard-coded in the transaction profile 
35 template 200. 
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At Step 1010, the transaction profile is received at the transaction 
controller 108. The XML template containing the extracted information Is received 
by the transaction controller 108 from the network interface 110. 

At step 1012, the transaction controller 108 identifies at least two 
5 transaction profiles meeting the limitations of each of the other of the at least two 
transaction profiles. The transaction controller 108 analyzes the limitations as 
described by the each transaction profile to determine overlapping transaction 
criteria. The matching process is described In further detail below in reference to 
FIG. 11. 

10 At step 1 01 4, the received transaction profile is stored within the 

database 1 14. In the exemplary embodiment, the transaction profiles are stored 
in a hierarchical data stnjcture in order to facilitate the matching process by 
rapidly eliminating broad classes of non-matching profiles from the matching. 
At step 1016, the transaction controller 108 creates a transaction profile 

15 result. vector corresponding to the matches found for the transaction profile. The 
transaction information Included In the transaction profile result vector may 
include the identity of the marl<et parties 102 submitting transaction profiles 
having overlapping limitations, and the actual transaction profile or details 
therefrom. In the exemplary embodiment, the transaction profile result vector lists 

20 ail non-empty Intersections. Provided that details of the submitting parties are 
included within the transaction profile (e.g. buyer 402 specified himself as buyer 
402 and wild cards seller and seller 404 specified himself as seller and wildcards 
buyer) after intersection details of both parties appear In the Intersection result. 
At step 1018, the transaction profile result vector Is converted into an 

25 HTML formatted transaction infonnation Web page 600. 

At step 1020, the transaction infonmation Web page 600 is transmitted to 
the appropriate marl^et party 102. The information is presented to the marlcet 
party 102 through the Web browser using known techniques. 

As discussed above, XPL is a language of special XML elements which 

30 can be inserted within an XML document to represent flexibility in the value of a 
particular parameter. A given industry may have a DTD or XML Schema for XML 
Documents describing the contracts (i.e. commercial transactions) in that 
industry. During negotiations, a market party may want to describe not only a 
specific contract or transaction bur rather may wish to describe the transactions 

35 that interest them. These desired transactions may include some flexibility of the 

31 



wo 02/17194 



PCT/USOl/26158 



transaction terms such as delivery dates, the identity of the counter part, 
quantities and other terms which will occur readily to those skiiled in the art. 

The use of XPL documents allows this flexibility to be captured in a 
natural way which respects the structure of the XML document. Each XPL 
5 element represents a set of XML elements and the XPL element may be inserted 
in a given place in the document to describe which XML elements would be 
acceptable at that place in the document. 

Although the XPL can have a variety of semantics, a convenient example 
allows each XPL element to represent a set of XML elements which it matches. 
10 Each XPL document (i.e. XML document containing XPL elements) can be given 
a semantics by stating that each XPL document matches a given XML document 
if their root elements match. 

Table 1 

^pi element ftlppli? XML efem^P^s which match 

Ordinary XML element . Matches any other XML element provided 

their tags are the same and that they have 
2Q the same number of children which 

match pair-wise (recursively) 

Ordinary XML text Matches identical text only. 

25 <xpl:none/> None 

<xpl:any_element/> Any single XML element 

<xpl:range mn^^S" max="1 07> Any textual XML element containing a 
3Q well formatted number In the range 5 to 10. 

Those skilled In the art will recognize that the XPL language can be 
extended to provide a variety of convenient attributes. For example, the XPL 
language may be extended to deal with lists of XML elements such as 
35 <xpl:any_elementJl8t/> which matches any list of XML elements. 
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Table 2 below provides an exemplary algorithm utilized by the method of 
. identifying transaction profiles having overlapping limitations in accordance with 
the exemplary embodiment of the invention. For illustrative purposes, the method 
discussed in reference to Table 2 provides an exemplary matching technique for 
5 Identifying two transaction profile expressed in XPL that have overlapping 
limitations (intersect). The result of the match is a new resulting transaction 
profile, which represents the intersection of the original transaction profiles 
submitted by the two market parties 102, if no match is found, the intersection is 
an empty set that can be expressed, for example, as an XPL element, 

10 "<xpl:none/>'' which does not match any XML documents. 

If the two XPL documents (transaction profiles) to be compared are 
referred to as P and Q and the XPL document resulting from the Intersecting of P 
and Q (transaction profile) is labeled as R. then this Intersection R Is defined by 
saying that It matches a given XML document if and only if both P and Q match 

15 that XML document. Since each XPL document may represent multiple XML 
documents, P, Q, and R may match more than one XML document Those 
sl<ilied In basic mathematical techniques will readily be able to use the semantics 
above in Table 1 to verify that the intersection results given In Table 2 (below) 
are indeed intersections by this definition. 

20 In the exemplary embodiment, all coaesponding elements in matching 

transaction profiles must match (be the same). OthenA^ise, the transaction 
profiles are not considered to match. This rule applies recursively to all child 
elements of all the elements in the profiles except where an <xpl:any_element>' 
wild card in one makes the children of the corresponding element irrelevant. 

25 Even if only one pair of con-esponding elements does not match, the result is an 
empty intersection. 

As discussed above, the code mnning on a computer or processor can be used 
to implement the functions of the matching engine, network interface and server 
functions. Those skilled in the art will readily apply the teachings and techniques 
30 discussed in Table 2 to create computer code in any appropriate computer 
language for implementing the functionality of the matching process utilized by 
the transaction system 100. 

Table 2 



First element 



Second element 
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Ordinary XML text 


Ordinary XML text 


If equal the common text, else 
<xpl:none/> 


Ordinary XML 
element 


Ordinary XML element 


If tags unequal, <xpl:none/>. 
If no. of children unequal, 
<xpl:none/> 

If any pair of corresponding 
children has intersection 
<xpl:none/>, <xpl:none/> 
Else, return an XML element with 

intprQAPfinn c\f fhA two ni\/An 

elements' children. 


Ordinary XML text 


Ordinary XML element 


<xpl:none/> 


<anyjBiemenu> 


X 


y 

A 


<xpl:range> 


Ordinary XML text 


If that text is a number in a range 
then that number, else 
<xpl:none/> 


<xpl:range/> 


<xpl:range/> 


If no overlap, <xpi:none/> else 
<xpl:range/> with a minimum 
equal to the higher of the two 
minima and a maximum equal to 
the lower of the two maxima 



The matching procedure, therefore, detennines whether a newly 
. submitted transaction profile is compared to stored transaction profiles to 

5 detennine if any of the stored transaction profiles have overlapping limitations 
using the algorithm above. In other words, the matching engine 314 determines if 
the stored transaction profiles meet the transaction criteria described In the newly 
submitted transaction profile. The matching engine could intersect each incoming • 
transaction profile with all stored profiles and pass all non-empty intersections to 

10 the reporting 316 and/or clearing engines 318. Time and resource efficiency, 
however, may be gained by using indexing techniques to narrow the set of 
potential matching transaction profiles. Large categories of inrelevant profiles (I.e. 
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profiles which certainly cannot match) can be eliminated by indexing as 
described immediately below. 

In the exemplary embodiment, the matching engine performs an indexing 
procedure to efficiently match transaction profiles as follows. One or more 

5 indexes allow the group of potential matches to be reduced from the entire 

collection of stored transaction profiles to a smaller subset which is a superset of 
all matches with the particular transaction profile that is under examination. If 
more than two indexes are used, a small collection is provided either by merging 
the collections provided by the various indexes (i.e. finding their intersection) or 

10 by selecting the smallest collection returned. Each transaction profile from this 
small collection Is intersected with the incoming profile. If the intersection is non- 
empty, this transaction profile is added to the list of potential match reports to be 
passed to the reporting 316 and/or clearing engines 318. 

The following discussion provides an example relating to the matching of 

15 transaction profiles describing resistor transactions. Those skilled in the art will 
recognize the various extensions and modification to the described process and 
examples. In the example, the transaction profiles are indexed using a standard 
tree index based on the value of a specific parameter. The resistance of a 
resistor is selected from the transaction profile expressed in XPL using the XML 

20 path resistor-sale/ohms. A standard search tree is established that includes 
branches based on ranges of values of resistor-sale/ohms and lists, within its 
leaves, all stored transaction profiles with a given value of resistance. Given an 
incoming transaction profile with a well defined resistance (i.e. not a wild card), 
the index can be used to find all the stored transaction profiles with equal 

25 resistance. The transaction profiles that have other resistance values are, 
therefore, eliminated from the group of potential matching transaction profiles 
where the elimination occurs in a time duration logarithmically related to the 
number of such non-matching transaction profiles. 

This type of index Is not useful in the case where many of the stored 

30 transaction profiles (and also the incoming transaction profile) do not have well 
defined values for resistance but rather have wild cards, ranges or inter- 
dependence between the resistance and another parameter such as price. 

The exemplary embodiment has an indexing scheme refenred to herein 
as the semi-lattice scheme. This scheme uses the fact that each transaction 

35 
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profile is, semantically, a set of transactions (i.e. its constraints define the set of 
transactions which meet those constraints). 

For example, the XPL language may have semantics, as discussed 
above, in which each XML document containing XPL elements either matches dr 
5 does not match any given XML document without XPL elements ("simple XML") 
so that each XML document with XPL represents a set of simple XML 
documents. The exemplary set of semantics discussed above allows concepts 
from mathematical set-theory to apply. In particular, transaction profiles may be 
stored at the nodes of a directed acyclic graph (DAG) with the following 
10 properties. 

Existence of root - there is a single root element which is the 
transaction profile which represents the set of all transactions (or of all 
transactions matching the schema of the marketplace) 

Ordering - if there is an edge from transaction profile p to transaction 
15 profile q then p is a superset of q. 

Uniqueness - no two nodes have the same transaction profile. 

Transitive reduction - if a transaction profile p has edges to both q and r ^ 
then q is not a subset of r. 

Completeness - if node p is a superset of node q then there is a path 
20 from p to q. 

Closure - if there are nodes p and q then there is a node with the 
intersection of p and q. 

FIG. 11 is an illustration of an example of the use of indexing. The 
transaction profile 1 100 describes Smith offering to sell his Blue Ford. All Cars 
25 1 102 is the root. The ordering is clearly preserved since every Blue Ford 1 104 is 
a Ford 1 106. The nodes are clearly unique. Transitive reduction can be tested. 
Transitive reduction would be broken if, for example, an edge was added directly 
from All Cars 1 102 to Blue Fords 1 104. Completeness may also be checked. 
Closure is also satisfied since the intersection of Blue Cars 1 108 with Fords 1 106 
30 (the only pair in which one does not contain the other) is Blue Fords 1 104. This 
structure is suitable for containing transaction profiles with wild cards which 
semantically are sets, whereas many traditional indexes such as those found In 
SQL databases assume that discrete values are being stored. 

In order to search for matches with an lncomln*g profile p the following 
35 procedure may be followed. First, all children of the root are checked to see if 
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any of them contain p: If so, the children of that element are recursively 
searched to see if any of them contain p. This Is repeated until a node is found 
which contains p but which has no children which contain p. This Is the unique 
smallest node containing p. The search for matches with p may be limited to the 

5 descendents of p since it follows from the axioms that for every node q such that 
p and q have non-empty intersections, the intersection of p and q exists as a 
node and is a descendent of p. 

In order for this search structure to be effective it may be necessary to 
create nodes with broad transaction profiles which effectively group together 

10 certain classes of transaction profiles (e.g. it may be that no buyer 402 or seller is 
offering all Blue Cars 1 208 but such a transaction profile has been added in order 
to create a DAG structure with bounded branching). 

Therefore, the transaction controller 108, coupled within a transaction 
management system 100 through a network interface 110. receives a plurality of 

15 transaction profiles submitted by a plurality of market parties 102 through the 
communication network. 106, Each of the transaction profiles describes one or 
more acceptable transactions to the market party 102 submitting the transaction 
profile and may indicate a level of intended commitment by the market party 102. 
The transaction controller 108, using the matching engine 314, matches 

20 transaction profiles by identifying transaction profiles with overlapping limitations. 
Each of the transaction profiles may correspond to a different market party class. 
Accordingly, a potential transaction can be formulated based on the transaction 
profiles submitted by market parties 102 from more than two market party 
classes. The results of the matches are conveyed to the market parties 102 

25 through a Web browser or email. Transaction profiles describing different levels 
of commitment may be matched allowing a variety of transactions to be 
performed. 

FIG. 12 is flow chart of a method of Identifying groups of transaction 
profiles submitted from a plurality of market parties (102) belonging to three or 
30 more market party classes. 

At step 1202, the transaction controller 108 receives a plurality of 
transaction profiles submitted by market parties (102) belonging to at least three 
different market party classes. Several market parties (102) from each market 
party class may submit transaction profiles which are processed as described 
35 above and stored in the database 114. 
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At step 1204, the transaction controller 108 identifies a group of 
transaction profiles where each transaction profile of the group meets the 
limitations of each of the other transaction profiles of the group. Any number of 
methods can be used to provide the transaction controller with the transaction 
5 profile Information. For example, if a transaction requires three market parties 
102 and a match is found with two of the parties, the two party match can be • 
retrieved from the database 1 14 and compared to a recently submitted 
transaction profile from the third market party class. 

Each transaction profile can have any number of limitations defining one 
10 or more potential (suggested) transactions. The limitations may be transaction 
attributes such as price 212. quantity 214. delivery date, identity of party, 
characteristic of party or any other transaction attribute as described above. If the 
transaction profile includes one or more limitations that define a range, wildcard 
or other plurality of values, the transaction profile describes more than one 
15 potential transaction. Each transaction profile of the group meets all the 

limitations of each of the other transaction profiles if none of the limitations is. 
inconsistent with the corresponding limitation In the other transaction profiles. If a 
particular limitation of a transaction profile provides an acceptable range to a 
particular transaction attribute, the corresponding limitation in each of the other 
20 transaction profiles must have at least one value in common with the limitation. In 
other words, each limitation must overlap with every other associated limitation of 
the transaction profiles of tiie group. 

At step 1206, a resulting transaction profile 900 is formed for each group 
of transaction profiles. Each resulting transaction profile 900 may have any 
25 number of limitations where each limitation may define a single value, a range of 
values, or an Infinite number of values using a range, wildcard or partial wildcard. 
In the exemplary embodiment, a resulting transaction profile 900 Includes an 
aggregate limitation when limitations of two or more parties are combined to 
meet the limitation of another market party 102. Since each of the limitations is 
30 dependent on the other associated limitations, each limitation Is a combination of 
the other limitations. For example, ttte maximum purchase price specified by a 
buyer 402 must be greater ti^an the sum of the selling price of the seller 404 plus 
the carrier fee for shipping the product. The aggregate limitation In this case 
could be defined as the sum of the carrier and seller limitation, if defining the 
transaction from the point of view of the buyer 402. The aggregate limitation 
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could also be the difference between the buyer's maximum purchase price and 
the carrier fee if looking at the transaction from the seller's 404 point of view. 
Accordingly, an aggregate limitation is defined as the combination of limitations 
of transaction profiles submitted by market parties 102 other than the submitting 

5 party, where the submitting party is the party intended to receive infomiation 
regarding the resulting transaction profiles. An aggregate limitation is, therefore, 
observed from the view point of the submitting market party 102. 

The aggregate limitation meets the associated limitation of the submitting 
party. Continuing with the example provided immediately above, if the buyer 402 

10 is the submitting party, the maximum purchase price is the limitation associated 
with the aggregate limitation and the aggregate limitation is the sum of the 
seller's minimum price and the carrier's minimum price. If all three parties are 
included in a resulting transaction profile 900, the buyer's maximum purchase 
price Is greater than the aggregate limitation. 

15 At step 1208, the resulting transaction profiles 900 are prioritized using an 

optimization function. An exemplary method of peri'orming the optimization 
procedure is discussed below in reference to FIG 13. 

At step 1210, transaction information is presented to the market parties 
102 by transmitting and displaying at least an indication that matching transaction 

20 profiles have been identified. In the exemplary embodiment, optimization 

information is displayed to the market party 102 in accordance with market party 
class of the particular market party 102 receiving the optimization information. 
The transaction Infomiation can be displayed any number of ways and may omit 
or include various information depending on the particular mari<et party 102 

25 receiving the information, the mari<et, the type of transaction or any other 
appropriate factor. The optimization information may include a prioritized list of 
resulting transaction profiles 900 ranked in accordance with the optimization 
function, a single resulting transaction profile 900 determined to be the best 
combination for the particular market party 102 or a prioritization of individual 

30 resulting transactions which may be defined by any number of resulting 
transaction profiles 900. The examples immediately below illustrate some of 
these scenarios. 

For the following examples, three market parties 102 are required for a 
particular transaction including a buyer 402, a seller 404 and a transaction 
35 enabler 406, In the interest of simplicity, the following scenarios focus on the 
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transactions from the perspective of the buyer 402. The buyer 402 submits a 
transaction proflie including several limitations that define several acceptable 
values allowing the transaction profile to describe several acceptable (suggested) 
transactions. Several sellers 404 and several transaction enablers 406 each 

5 submit a transaction profile defining more than one suggested transaction. The 
transaction controller 108 identifies several resulting transaction profiles 900 
where each resulting transaction profile 900 involves a different pair of sellers 
404 and transaction enablers 406. 

In one scenario, a prioritization list of resulting transaction pnjfiles 900 is 

10 fornied based on the optimization function which is defined to minimize the total 
purchase price to the buyer 402. The resulting transaction profiles 900 are 
ranked based on the most attractive potential transaction defined by the resulting 
transaction profile 900. For example, a resulting transaction profile 900 may 
Include a limitation defining a range of total costs to the buyer 402 to enter Into a 

15 transaction based on a selling price and a delivery cost associated with a single 
seller 404 and single transaction enabler 406. Another resulting transaction 
profile 900 may have a similar limitation defining a different range of total costs 
associated with, the buyer 402 for a different seller 404 and transaction enabler 
406 combination. The resulting transaction profiles 900 are ranked based on the 

20 lowest possible associated cost to the buyer 402. The prioritization list is 

displayed to the buyer 402 without Indicating the particular transaction defined by 
each resulting transaction profiles 900 that resulted In the particular ranking 
order. 

In a second scenario, the individual transactions defined by each of the 
25 resulting transaction profiles 900 is used to form a prioritization list of potential 
transactions which is displayed to the buyer 402. In this scenario, the buyer 402 
does not receive a list of the resulting transactton profiles 900 but receives a list 
of the optimum transactions offered by all of the resulting transaction profiles 
900. 

30 In another scenario, a single transaction offering the most attractive terms 

Is displayed to the buyer 402. Various other scenarios can be addressed and 
different infonnation and combinations of Information can be displayed to each of 
the mari<et parties (1 02). 

In the exemplary embodiment, the system 100 performs an optimization 

35 procedure that calculates an optimum transaction scenario for a particular market 
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party 1 02. The optimum transaction for a market party 1 02 may not necessarily 
be the combination of the transaction profiies providing the best set of transaction 
terms as observed on an individual transaction profile basis. For example, if a 
buyer 402 is willing to purchase 100 units at a price of 3 dollars per unit including 

5 shipping cost for a delivery schedule of three days to Los Angeles, the optimum 
transaction may not be the combination of the carrier offering the lowest cost and 
shortest delivery schedule coupled with the seller 404 providing the product at 
the lowest cost. For this example. Company X in Chicago offers to sell 100 units 
for $1 .90/unit and Company Y In New York offers to sell the units for $1 .50 per 

10 unit. Further, Company X will guarantee that the units will be ready for shipping 
within 2 days and Company Y will guarantee that the products will be ready for 
shipping within one day. Carrier A will provide shipping from anywhere in the U.S. 
to Los Angeles for $1.50/unll and will guarantee delivery within 2 days. Carrier B 
also will providing shipping from anywhere in the US to Los Angeles for 1.50 with 

15 a guaranteed delivery of 2 days. Carrier B, however, has a distribution hub in 
Chicago and will provide shipping from Chicago to Los Angeles for $1 .00 and will 
guarantee delivery within 1 day from the time a shipment is picked up in Chicago. 
Therefore, in this case the buyer 402 could obtain the best overall deal by 
purchasing the products from Company X even though the selling price per unit 

20 is more than the selling price of Company Y. if the units are purchased from 
company Y. the units can be delivered by either Carrier A or Caaier B within 
three days since the Company Y will provide units for shipping within 1 day and 
both carriers can deliver the units within two days resulting in a total cost per unit 
of $3.00. If the units are purchased at the higher price fre»m Company X In 

25 Chicago, however, the total cost per unit including the Carrier B shipping charge 
is only $2.90. 

The optimization procedure is based on an optimization function that may 
include one or more parameters such as transaction terms or transaction 
attributes. The optimization function may be an Industry standard optimization 

30 function accepted by the particular market or may be a function specified by the 
market party 102 (submitting market party) that will receive the prioritization list of 
the transactkjn profiles. For example, the buyer 402 may provide an optimization 
function spedfying that the total cost of the transactkjn be minimized. Also an 
Industry standard optimization function may provide that the total cost to a buyer 

35 402 be minimized to provide a prioritized list of transaction profiles to a buyer 
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402, The potential optimization functions are almost limitless and other examples 
include ranking the potential transactions based on delivery date, minimum 
quantity that can be sold and delivered or a total cost to a buyer 402 based on 
Insurance, carrier charges, and financing costs. A group of transaction profiles 

5 may be ranked differently based on the market party 1 02 that will receive the 
results. Accordingly, the same combinations of matching transaction profiles may 
be prioritized differently for each market party 102 of the potential transactions. 

FIG. 13 is flow chart of an exemplary optimization method for performing 
step 1206 of FIG 12. The method is perfonned at the transaction server 112 in 

10 the exemplary embodiment. 

At step 1302, the transaction server 112 obtains a set or resulting 
transaction profiles 900 corresponding to a submitting market party transaction 
profile. The procedure for obtaining the resulting transaction profiles 900 Is 
performed in accordance with the techniques discussed above. 

15 At step 1 304, the calculates the resulting values for each of the 

transaction terms for each of the resulting transaction profiles (900). Each 
combination of transaction tenms associated with a potential transaction is 
applied to an algorithm designed to evaluate the combination of tenms and 
produce a value indicating a transaction term value or a desirability of entering 

20 into a transaction. Various methods and optimizatton functions can be used to 
determine a particular resulting transaction value or Indicator. The appropriate 
method will depend on the particular industry, transaction value and system 100 
and will readily occur to those skilled In the art. For example, if the transaction 
value that is to be optimized for the buyer 402 is price 212, the various cost 

25 values for the seller 404 and transaction enablers 406 are added to produce a 
total cost to the buyer 402. 

Although various methods can be used to fadlltate the submission of 
transaction profiles that result In the optimization of resulting transaction profiles 
900. an exemplaiy technique allows the aggregation of limitations submitted 

30 using XPL elements. The following example includes a transaction Involving a 
buyer 402. seller 404 and a carrier. The seller 404 indicates a minimum of the 
seller's price and wildcats (I.e. allows any value) for the transport price. The 
carrier specifies a wildcard for the seller's price and indicates a minimum on the 
transport price. The buyer 402 specifies a maximum on the sum of the buyer's 

35 price plus the seller's price. 
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15 



An XPL element, <surn max="nnn7>, included in the transaction profile 
matches any element whose grandchildren are numbers adding up to less than 
nnn. The seller 404 submits a transaction profile including the following. 

<price> 

<$eller-price> <range min="mmm7> </seller-price> 
<transport-price> <xpl:any-element/> </tran$port-price> 
</price> 

The seller 404 submits a transaction profile Including the following, 
<prlce> 

<seller-price> <xpl:any-element/> </seller-price> 
<transport-prlce> <range min="mmm7> </transport-prlce> 
</price> 

The buyer 402 submits a transaction profile including the following. 



<price> 

<buyer-price> <sum max="nnn"/> </buyer-price> 
20 </price> 

The resulting transaction profiles 900 Involving the buyer 402 will include all 

combinations of seller 404 and carrier transaction profiles 808 resulting in a total 

buyer price less than nnn. 
25 Other examples Include similar specifications for shipping date, transit 

time and delivery date. Another example arises when the buyer 402 and seller 

404 are using different currencies and transaction enabler 406 provides a 

currency conversion service. 

The results to the buyer 402 can be presented by combining the two 
30 prices to show only a total cost to the buyer 402. The earner can be presented 

with a price equal to the difference between the buyer sum maximum and the 

seller's price to indicate the spread available to cover the transportation. 

At step 1306, the resulting transactions are prioritized based on one or 

more transaction terms. The transaction terms may be predetermined terms as 
35 appropriate for the particular industry or may be terms identified by the 

submitting martlet party 102, For example, the transaction server 112 may 
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prioritize the resulting transaction profiles 900 related to a buyer's transaction 
profile submission based on a total price per unit and on delivery date. The 
resulting transaction profiles 900 describing an overall lowest price will be 
identified as having highest priority. The buyer 402 may also provide optimization 
5 term corresponding to a transaction term that should be minimized or maximized 
to obtain the highest priority (optimum) transaction profile. The buyer 402, for 
example may wish to have the resulting transaction profile 900 prioritized in order 
of earliest delivery date. Further, any combination of market party optimization 
temis and predetermined optimization tenms may be used to form a prioritized list 
10 of resulting transaction profiles 900. 

At step 1308, the optimum resulting transaction profile 900 is sent to the 
market party 102. In the exemplary embodiment, a prioritized list of resulting 
transaction profiles 900 is'sent allowing the market party 102 to view the entire 
list. A single optimum resulting transaction profile 900 can be transmitted to the 
15 market party 102 in place of a list. The resulting Information Is transmitted as 
discussed above and the appropriate mechanism for transmission will depend on 
the party and the time the transaction profile was submitted. 

Therefore, transaction profiles.are received from a plurality of market 
parties 102 belonging to at least three different market party classes at the 
20 transaction controller 108. Resulting transaction profiles 900 are formed by 
matching the transaction profiles submitted from each class. A resulting 
transaction profile includes an aggregate limitation when transaction profiles 
submitted by two or more parties belonging to different market party classes are 
combined to form the aggregate limitation associated with a limitation included in 
25 a transaction profile of a submitting party. The aggregate limitation meets the 
limitation of the submitting market party 102. An optimization function is 
perfonned by applying an algorithm to the potential suggestions defined by the 
resulting transaction profiles 900. A prioritization list Is transmitted and displayed 
to the submitting market party. 
30 Cleariy, other embodiments and modifications of this invention will occur 

readily to those of ordinary skill in the art in view of these teachings. Therefore, 
this invention is to be limited only by following claims, which include all such 
embodiments and modifications when viewed In conjunction with the above 
specification and accompanying drawings. 
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APPENDIX I 

<car> 

<make> 

BMW 
</makG> 
<color> 

Black 
</color> 

<safety-features> 
<alr-bags> 
2 

</air-bags> 
<antl*lock brake8/> 
</8afety-features> 
</car> 
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Appendix II 

<car> 

<xnake> 

BMW 
</make> 
<color> 

<xpls choice valu©l«"Black'' value2o''Blua''/> 
</color> 

<sa£ety-£eaturas> 

<xpl:any-elesient-llst/> 
</8a£ety-£eatures> 
</car> 
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Appendix 111 



<resistor-sala> 
5 <ohins> 

1000 
</ohins> 

<price units"cents"> 
1,10 

10 </prloe> 

<transaGtion-partles> 
<buyer> 

<name> 

Electronics Procurement Inc 
15 </naine> 

<state> 
CA 

</state> 
< /buyer > 

20 <seller> 

<xpl:any-Glement-list/> 
</s0llor> 
</transaction-*partles> 
</resistor-sale> 

25 
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Appendix IV 

<resistor-sald> 
<ohnis> 

<xpl:range inin="100" max="10000'V> 
</ohins> 

<pric6 unit=" cents" > 

1*10 
</prica> 

< trans action-parties> 
<buyer> 

<naine> 

<xpl : any*- element /> 
</naine> 
<state> 
CA 

</state> 
< /buyer > 
<seller> 

<naxae> 

Resistors Inc. 
</na2tie> 
<state> 
CA 

</state> 
</seller> 
</transaction-parties> 
</resistor-3ale> 
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Appendix V 

<resistor-sale> 
<ohins> 

10000 

5 . </oIms> 

<price \anito"Gents''> 

1.10 
</pric©> 

<transaction-partiea> 
10 <buyer> 

<:xiaine> 

Electronics Procurement Inc 
</naine> 
<state> 
CA 

</state> 
< /buyer > 
<seller> 

<naine> 

Resistors Inc. 
</name> 
<state> 
CA 

</8tate> 
25 </seller> 

</transaction-parties> 

</resi3tor-sale> 
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Appendix VI 

<gaz-sale xmlns : xp 1 =a " h t tp : //www • tradeuin . com" 
xmlns : tpts "ht tp : //www, tradeum. coin"> 

5 

<tpt:validtill/> 
<parties> 

<buy©r> 

10 <ept: originator > 

< / tpt : or iginator > 

<statu8><tpt : insert tdxt 

fields" status '■/></statu8> 
15 </buyer> 

<xpl : any_eleznent/> 
</parties> 

20 <quantity> 

<xpl : remge mln= " tpt : minquanti ty " 
ittaxa»tpt:maxquantity" pref era"up"/> 
</quantity> 

25 <prioe> 

<xpl:range mins"0" maxa^tpt xprice" 

pr e f er s* " down " / > 

</price> 
<sourc©> 

30 <xpl : anyelementlist/> 

</source> 
. <ddstination> 
<state> 

<tpt:in8erttext £leldonstate>*> 

35 
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<tpt: error toxta"<h2>Please 
specify your state. Press the Back button' to 
continue. </h2>"/> 

</tpt: insert text> 
5 </state> 

<2ip> 

<tpts insert text field»"zip"> 

<tpt terror text-"<h2>Please 
specify your zip code. Press the Back button to 
10 continue . </h2 > " /> 

</tpt 2 insert text> 
</zip> 
</destination> 
<delivery> 

15 

<xpl : daterange pref er""down"> 
<date> 

<year> 

<tptsin8erttext 

20 field="firstyear"/> 

</year> 
<inonth> 

<tpt:inserttext 

fields "firstmonth"/> 
25 </inonth> 

<day> 

<tpt:inserttext 

fielda"firstday"/> 

</day> 

30 </date> 

<date> 

<year> 

<tpt : inserttext 

f i elds " 1 as tyear " /> 
35 </year> 

<month> 

51 
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<tpt t insert text 

fieldo"lastmohth"/> 

< /month > 
<day> 

5 <tpt;inserttext 
fielda"lastday"/> 

</day> 
</date> 
</3cpl : daterange> 
10 </delivery> 
<grade> 

<fcpt:inserttext fields "grade" /> 
</grade> 
<RVP> 

15 <xpl: range mina"tpt rminrvp" 

maxa"tpt:inaxirvp" pre£era"up"/> 
</RVP> 
<MTBS> 

<xpl:rsmge mlnantptmlnmtbe" 
20 inax="tpt:inaxnitbe'' pref era"up"/> 
</MTBE> 
<Sthanol> 

<xpl: range mins^^tptiminethynol" 
max»"tpt:inaxethynol" prefera"up"/> 
25 </Bthanol> 
</gaz*sale> 
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CLAIMS 

1 . A method comprising: 

receiving a plurality of transaction profiles from a plurality of 
5 market parties, each transaction profile of the plurality of transaction profiles 
comprising a limitation to a suggested transaction; and 

identifying a group of transaction profiles received from market 
parties of at least three market party classes, each transaction profile of the 
group meeting the limitation of each other transaction profile of the group. 

10 

2. A method in accordance with claim 1. wherein each transaction profile 
of the transaction profiles of the group comprises any number of limitations, each 
transaction profile meeting all the limitations of each other transaction profile of 
the group. 

15 

3. A method in accordance with claim 2. wherein each of the limitations of 
the any number of limitations comprises a plurality of limitations. 

4. A method in accordance with daim 3, vrtiereln a first limitation of a first 
20 transaction profile of the group of transaction profiles comprises a first 

transaction attribute range including at least two values of a transaction attribute, 
each of the limitations of the other transaction profiles of the group comprising at 
least one value of the first transaction attribute range. 

25 5. A method in accordance with claim 4, wherein a second limitation of a 

second transaction profile of the group of transaction profiles comprises a second 
transaction attribute range including at least two values of the transaction 
attribute, wherein the second transaction attribute range includes at least one 
value within the first transaction attribute range. 

30 

6. A method in accordance with claim 4, wherein the first limitation is a 
wild card defining an infinite range of values for the transaction attribute. . 

7. A method in accordance with claim 6, wherein the first limitation is a 
35 partial wild card defining an infinite range of values excluding at least one value. 
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8. A method in accordance with claim 5, wherein each transaction profile 
of the group of transaction profiles comprises a plurality of limitations to the 
suggested transaction, each limitation of the plurality of limitations of a 

5 transaction profile associated with a corresponding limitation of each of the other 
transaction profiles of the group and comprising at least one value within the 
corresponding limitation in each of the other transaction profiles. 

9. A method in accordance with claim 1, further comprising: 

10 forming at least one resulting transaction profile having limitations 

consistent with each other transaction profile of the group of transaction profiles. 



10. A method In accordance with claim 9, further comprising: 

transmitting the at least one resulting transaction to at least one 

15 mart<et party. 

1 1 . A method in accordance with claim 9, wherein the at least one 
resulting transaction profile defines a plurality of resulting potential transactions. 

20 1 2. A method in accordance with claim 1 1 , further comprising: 

prioritizing the plurality of resulting potential transactions based on an 
optimization function. 

13. A method In accordance with claim 12. wherein the optimization 
25 function 

is defined by a market standard. 

14. A method in accordance with claim 12. wherein the optimization 
function 

30 Is defined by a market party. 

15. A method in accordance with claim 12, wherein the prioritizing 
produces an optimum resulting transaction, the method further comprising 
displaying the optimum resulting transaction to a market party submitting one of 

35 the transaction profiles of the group. 
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16. A method in accordance with claim 12, wherein the prioritizing 
produces a list of resulting potential transactions, the method further comprising 
displaying the list to a market party submitting one of the transaction profiles of 

5 the group. 

17. A method in accordance with claim 12, wherein the at least one 
transaction profile comprises a plurality of resulting transaction profiles, each of 
the plurality of resulting transaction profiles defining at least one resulting 

10 potential transaction to create a plurality of resulting potential transactions, the 
method further comprising: 

prioritizing the plurality of resulting potential transactions to 
produce a 
transaction prioritization. 



15 



.18. A method In accordance with claim 17, further comprising: 

prioritizing the plurality of transaction profiles based on the 
transaction prioritization. 



19. A method In accordance with claim 9, wherein the at least one 
resulting transaction profile comprises a plurality of resulting transaction profiles, 
the method further comprising: 

prioritizing the plurality of resulting transaction profiles based on 
an optimization functions. 

20. A method In accordance with claim 19, wherein the optimization 
function is defined by a market standard. 

21. A method in accordance with claim 19, wherein the optimization 
30 function is defined by a market party. 

22. A method in accordance with claim 19, wherein the prioritizing 
produces a prioritization list of resulting transaction profiles, the method further 
comprising: 

35 displaying the prioritization list to the submitting party. 



20 



25 
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23. A method in accordance with claim 19, wherein the prioritizing - 
produces an optimum resulting transaction, the method further comprising: 

displaying the optimum resulting transaction to the submitting party. 

5 

24. A method In accordance with claim 19, further comprising: 
receiving an optimization function from a submitting market party of the 

gnDup of market parties, the optimization function Indicating a procedure for 
prioritizing the piuraiity of resulting transaction profiles. 

10 

25. A method in accordance with claim 1, wherein the limitation comprises 
a transaction attribute of the suggested transaction. 

26. A method in accordance with claim 25, wherein the transaction 
15 attribute is a price. 

27. A method in accordance with claim 25, wherein the transaction 
attribute is quantity. 



20 28. A method in accordance with claim 25, wherein the transaction 

attribute is a quality indicator. 

29. A method in accordance with claim 25, wherein the transaction 
attribute is a delivery date. 

25 

30 A method in accordance with claim 25, wherein the transaction 
attribute is a credit term. 

31. A method in accordance with claim 25, wherein the transaction 
30 attribute is a currency. 

32, A method in accordance with claim 25, wherein the limitation Is a 
market party identifier 
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33. A method in accordance with claim 32, wherein the market party 
identifier identifies a submitting market party submitting the transaction profile 
including the market party identifier 

5 34. A method in accordance with claim 33, wherein the transaction 

attribute is a name of the submitting market party. 

35. A method in accordance with claim 32, wherein the market party 
identifier identifies a market party other than a submitting market party submitting 

10 the transaction profile including the market party identifier. 

36. A method in accordance with claim 25, wherein the limitation is a 
market party characteristic. 

15 37. A method in accordance with claim 36, wherein the market party 

characteristic is a market party characteristic of a market party other than a 
submitting market party. 

38. A method in accordance with claim 37, wherein the market party 
20 characteristic is a credit rating. 

39. A method in accordance with claim 37, wherein the market party 
charactertstic is a geographical location. 

25 40. A method in accordance with claim 9. wherein the resulting 

transaction profile comprises a plurality of limitations, each of the plurality of 
limitations defined within the limitations of each of the transaction profiles of the 
group. 

30 41 . A method in accordance with claim 40. wherein the plurality of 

limitations are defined by an intersection of the limitations of each of the 
transaction profiles of the group with each other transaction profile of the group. 
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42. A method In accordance with claim 41 , wherein the plurality of 
limitations are defined by a combination of the limitations of each of the 
transaction profiles of the group with each other transaction profile of the group. 

5 43. A method In accordance with claim 9, further comprising transmitting 

the resulting transaction profile to at least one of the market parties of the group. 

44. A method in accordance with claim 43, wherein the at least one of the 
market parties comprises all the market parties within the group. 

10 

45. A method in accordance with claim 43, further comprising displaying 
the resulting transaction profile. 

46. A method in accordance with claim 45, wherein the resulting 
15 transaction profile comprises: 

a plurality of the market parties of the group. 

47. A method in accordance with claim 45, wherein the resulting 
transaction profile comprises: 

20 plurality of resulting transaction profiles. 

48. A method in accordance with claim 47. wherein each of the plurality 
of resulting transaction profiles comprises: 

a resulting transaction attribute for each transaction attribute 
25 submitted in the transaction profile submitted by a submitting market 

party receiving the resulting transaction profiles transaction profile. 

49. A method in accordance with claim 48. wherein each of the plurality 
of resulting transaction profiles further comprises: 

30 a market party identifier. 

50. A method In accordance with claim 47, wherein plurality of transaction 
profiles are prioritized. 
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51. A method in accordance with claim 1, wherein the hiarket party 
classes comprise: 

a buyer class corresponding to buyers having an Interest In 
obtaining an article of commerce; 
5 a seller class corresponding to sellers having an Interest to 

provide the article of commerce; and 

an enabler class corresponding to enablers having an interest to 
enable a transaction between at least one market party of the buyer class and at 
least one market party of the seller class. 

10 

52. A method in accordance with claim 51, wherein the enabler is a 
logistics carrier. 

53. A method in accordance with claim 51, wherein the enabler is a 
15 financier. 

54. A method in accordance with claim 51, wherein the enabler is an 

insurer. 

20 55. A method in accordance with claim 51, wherein the enabler is an 

foreign currency exchanger. 

56. A method in accordance with claim 51. wherein the market parties 
from the at least three market party classes include at least two market parties 

25 from the enabler class. 

57. A method in accordance with claim 56, wherein the at least two 
market parties from the enable class are selected from the group consisting of 
logistic carrier, insurer, financier, and foreign currency exchanger. 

30 

58. A method in accordance with claim 1, wherein the limitation of at 
least one of the transaction profiles comprises a value range corresponding to a 
transaction attribute of the suggested transaction. 
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59. A method in accordance with claim 1, wherein the limitation of at least 
one of the transaction profiles comprises a wild card corresponding to a 
transaction attribute of the suggested transaction, the wild card indicating an 
unlimited range. 

5 

60. A method in accordance with claim 1, wherein the limitation of at least 
* one of the transaction profiles comprises a partial wild card corresponding to a 

transaction attribute of the suggested transaction, the partial wild card indicating 
a range only bounded by a single limit. 

10 

61. A method comprising: 

receiving, through a packet switched networl<. a plurality of 
transaction profiles from a plurality of market parlies, each transaction profile of 
the plurality of transaction profiles comprising a limitation to a suggested 
15 transaction.; 

identifying a group of transaction profiles received from market 
parties of at least three market party classes, each transaction profile of the 
group meeting the limitation of each other transaction profile of the group; 

creating a resulting transaction profile having a set of limitations 
20 defined by the limitation of each transaction profile of the group; and 

transmitting the resulting transaction profile through the packet 
switched network to at least one market party submitting a transaction profile of 
the group. 

25 62. A transaction server comprising: 

a network Interface adapted to receive a plurality of transaction 
profiles through a communication network from a plurality of market parties of at 
least three maricet party classes, each transaction profile of the plurality of 
transaction profiles comprising a limitation to a suggested transaction; and 

30 a transaction controller coupled to the network interface, the 

transaction controller adapted to identify a group of transaction profiles, each 
transaction profile of the group meeting the limitation of each other transaction 
profile of the group. 
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63. A transaction server in accordance with claim 62, wherein a limitation 
of a first transaction profile of the group of transaction profiles comprises a 
plurality of limitations. 

5 ' 64. A transaction server in accordance with claim 63, wherein the first 

limitation of the first transaction profile of the group of transaction profiles 
comprises a first transaction attribute range including at least two values of a 
transaction attribute, each of the limitations of the other transaction profiles of the 
group comprising at least one value of the first transaction attribute range, 

10 

65. A transaction server in accordance with claim 64. wherein a second 
limitation of a second transaction profile of the group of transaction profiles 
comprises a second transaction attribute range including at least two values of 
the transaction attribute, wherein the second transaction attribute range includes 

15 at least one value within the first transaction attribute range. 

66. A transaction server in accordance with claim 64, wherein the first 
limitation is a wild card defining an infinite range of values for the transaction 
attribute. 

20 

67. A transaction server In accordance with claim 64, wherein the first 
limitation is a partial wild card defining an infinite range of values excluding at 
least one value. 

25 68. A transaction server in accordance with claim 66, wherein each 

transaction profile of the group of transaction profiles comprises a plurality of 
limitations to the suggested transaction, each limitation of the plurality of 
limitations of a transaction profile associated with a conrespondlng limitation of 
each of the other transaction profiles of the group and comprising at least one 

30 value within the conrespondlng limitation in each of the other transaction profiles. 

69. A transaction server in accordance with claim 62, wherein the 
limitation comprises a transaction attribute of the suggested transaction. 
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70. A transaction server in accordance with claim 69, wherein the 
transaction attribute is a price. 

71 . A transaction server in accordance with claim 69, wherein the 
5 transaction attribute is quantity. 

72. A transaction server in accordance with claim 69, wherein the 
transaction attribute is a quality indicator. 

10 73. A transaction server In accordance with claim 69, wherein the 

limitation is a market party identifier. 

74. A transaction server in accordance with claim 73. wherein the marl<et 
party identifier identifies a submitting market party submitting the transaction 

15 profile including the market party identifier. 

75. A transaction server in accordance with claim 74, wherein the 
transaction attribute is a name of the submitting market party. 

s 

20 76. A transaction server in accordance with claim 73, wherein the market 

party identifier identifies a market party other than a submitting market party 
. submitting the transaction profile including the market party identifier. 

77. A transaction server in accordance with claim 62, further comprising: 
25 determining a resulting transaction profile having a limitation 

defined by the limitations of each of the transaction profiles of the group. 

78. A transaction server in accordance with claim 77, wherein the 
resulting transaction profile comprises a plurality of limitations, each of the 

30 plurality of limitations defined within the limitations of each of the transaction 
profiles of the group. 

79. A transaction server In accordance with claim 77, further comprising 
transmitting the resulting transaction profile to at least one of the market parties 

35 of the group. 
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80. A transaction server in accordance with claim 79, further comprising 
displaying the resulting transaction profile. 

5 81 . A transaction server in accordance with claim 77, wherein each of the 

plurality of transaction profiles comprises a transaction profile type indicating the 
level of market party commitment. 

82. A transaction server In accordance with claim 81 . wherein the 
10 transaction profile type comprises an anonymous search request requesting a 
search for other transaction profiles meeting the limitation of the transaction 
profile, the transaction profile type indicating a market party commitment limited 
to anonymously providing Information related to the transaction profile. 

15 83. A transaction server In accordance with claim 81 , wherein the 

transaction profile type comprises a non-anonymous search request requesting a 
search for other transaction profiles meeting the limitation of the transaction 
profile, the transaction profile type indicating a market party commitment limited 
to providing an identity of the market party submitting the non-anonymous search 

20 request and infonmation related to the transaction profile. 

84. A transaction server in accordance with claim 81, wherein the 
transaction profile type comprises an offer to enter into a transaction another 
market party submitting another transaction profile meeting the limitation of the 

25 transaction profile, the transaction profile type indicating a market party 
commitment to be legally bound to the transaction. 

85. A transaction server in accordance with claim 81 . wherein the 
transaction profile type comprises an expression of interest to enter into a 

30 transaction with another market party submitting another transaction profile 
meeting the limitation of the transaction profile, the transaction profile type 
Indicating a market party commitment to continue to a next level of negotiation 
with the another market party. 
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86. A graphical user Interface providing a communication interface 
between a submitting market party and a transaction server, wherein the 
transaction server is adapted to receive a plurality of transaction profiles, the 
graphical user interface comprising: 

5 a first transaction attribute field adapted to accept a first 

transaction attribute chosen by the submitting marl<et parly, the first transaction 
attribute describing at least one limitation to a suggested transaction and directed 
to a first class of market parties; and 

a second transaction attribute filed adapted to accept a second 

10 transaction attribute chosen by the submitting market party, the second 

transaction attribute describing at least one limitation to the suggested 
transaction and directed to a second class of market parties. 

87. A graphical user interface in accordance with claim 86, wherein the 
15 first transaction attribute can only meet the limitation submitted by a first market 

party of the first market party class and a transaction can only be formed if the 
first market party submits a limitation to the first transaction attribute that meets 
the limitation of the first transaction attribute submitted by the submitting party. 

20 88. A graphical user interface in accordance with claim 87, wherein the 

second transaction attribute can only meet the limitation submitted by a second 
market party of the second market party class and a transaction can only be 
formed if the second market party submits a limitation to the second transaction 
attribute that meets the limitation for the second transaction attribute submitted 

25 by the submitting party. 

89. A method comprising: 

receiving a first plurality of transaction profiles from a first market 

party class; 

30 ' receiving a second plurality of transaction profiles from a second 

market party class; 

receiving a third plurality of transaction profiles from a third market 
party class, each transaction profile of the plurality of transaction profiles 
comprising at least one limitation to a suggested transaction; and 
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identifying at least one transaction profile from each of the market 
party classes, the at least one transaction meeting the limitations of each 
transaction profile of other the at least two transaction profiles. 

5 90. A method comprising: 

receiving a plurality of transaction profiles submitted by a plurality 

of market parties of at least three classes, each of the transaction profiles 

comprising any number of limitations, each of the transaction profiles defining at 

least one corresponding suggested transaction; and 
10 identifying a group of transaction profiles, wherein each 

transaction profile of the group meets all the limitations of each other transaction 

profile of the group. 

91. A method in accordance with claim 90. further comprising: 

15 forming a resulting transaction profile defining at least one 

potential resulting transaction meeting the limitations of every transaction profile 
of the group. 

92. A method in accordance with claim 91. wherein the resulting 
20 transaction profile defines a plurality of potential transactions, 

93. A method in accordance with claim 91, wherein the resulting 
transaction profile includes an aggregate limitation to the at least one potential 
resulting transaction, the aggregate limitation associated with a limitation of one 

25 of the transaction profiles of the group and defined by a combination of limitations 
of two or more of the other transaction profiles of the group. 

94. A method in accordance with claim 93, further comprising: 

identifying a plurality of combinations of transaction profiles of the 
30 group, wherein each combination defines at least one potential resulting 
transaction. 

95. A method in accordance with claim 94, further -comprising: 

prioritizing the plurality of combinations based on an optimization 

35 function. 
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96. A method in accordance with claim 95. wherein the prioritizing 
comprises: 

determining an optimum potential resulting transaction associated 
5 with each combination of the plurality of combinations to form a plurality of 
optimum potential resulting transactions; and 

ranl<ing the plurality of optimum potential resulting transactions in 
order of a lil<ely desirability of an identified market for entering into a transaction 
having limitations in accordance with the plurality of optimum potential resulting 
10 transactions. 

97. A method in accordance with claim 96, wherein the ranking produces 
a prioritization list of optimum potential resulting transactions, the method further 
comprising: , 

15 displaying at least a portion of the prioritization list to the 

identifying party. 

98. A method in accordance with claim 93, wherein the resulting • 
transaction profile defines a plurality of potential resulting transactions. 

20 

99. A method in accordance with claim 98, wherein the aggregate 
limitation comprises a range of values. 

100. A method in accordance with claim 98, wherein the aggregate 
25 limitation comprises a wild card, 

101. A method in accordance with claim 93, wherein the combination is a 
sum of a seller limitation of seller transaction profile and a enabier limitation an 
enabler transaction profile. 

30 

102. A method in accordance with claim 101, wherein the aggregate 
limitation is associated with a buyer limitation of a buyer transaction profile. 

1 03. A method in accordance with.clalm 102, wherein the buyer limitation 
35 Is a total cost to a buyer for the corresponding suggested transaction, the seller 
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limitation is a selling price for tlia corresponding suggested transaction, and the 
enabler limitation is a cost of enabling tlie transaction. 

104. A method in accordance with claims 103 wherein the enabler 

5 limitation Is a cost to the buyer for shipping a product from the seller to the buyer, 

105. A method in accordance with claim 91, wherein the receiving ' 
comprises: 

receiving a first transaction profile from a first market party of a 
10 first market party class including a limitation to a first attribute relevant to market 
parties of the first market party class; 

receiving a second transaction profile from a second market party 
of a second market party class including a limitation to a second attribute 
relevant to market parties of the second market party class; and 
15 receiving a third transaction profile from a third market party of a 

third market party class including a limitation to a third attribute relevant to 
market parties of the third market party class, wherein the third attribute Is 
arithmetically related to the first and second attributes and the limitation of the 
third attribute is calculated to allow values of ttie third attribute which are 
20 consistent with a relationship between the third attribute to the first and second 
attributes and to the limitations on the first and second attributes. 

106. A method according to 105 wherein the first attribute comprises a 
purchase price, the second attribute comprises a sale price and the third attribute 

25 comprises a cost of a enabler market party. 

107. A method according to 105. wherein the limitation on the third 
attribute is further calculated in accordance with a limitation on the third attribute 
in a transaction profile of a market party of the third class. 

30 

108. A method according to 1.05, further comprising: 

displaying the resulting transaction profile to a plurality of maricet • 
parties, without displaying attributes relevant to other market party classes. 

35 1 09. A transaction server comprising: 
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a communication interface configured to receive a plurality of 
transaction profiles submitted by market parties of at least three classes, each of 
the transaction profiles comprising any number of limitations to a suggested 
transaction; and 

5 a transaction controller communicatively coupled to the 

communication inteiface and configured to identify a group of transaction 
profiles, wherein each transaction profile of the group meets all the limitations of 
each other transaction profile of the group. 

10 1 1 0. A transaction server iri accordance with claim 1 09, wherein the 

transaction server is further configured to form a resulting transaction defining a 
set of transactions, wherein each of the transactions meets all the limitations of 
each of the transaction profiles of the group. 
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